Network Working Group                                              N. So
Internet-Draft                                                  A. Malis
Intended status: Standards Track                              D. McDysan
Expires: April 24, 2009                                          Verizon
                                                                 L. Yong
                                                              Huawei USA
                                                        October 21, 2008


     Framework and Requirements for Composite Transport Group (CTG)
            draft-so-yong-mpls-ctg-framework-requirement-00

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on April 24, 2009.















So, et al.               Expires April 24, 2009                 [Page 1]

Internet-Draft       CTG framework and requirements         October 2008


Abstract

   This document states a traffic distribution problem in today's IP/
   MPLS network when multiple links are configured between two routers.
   The document presents a Composite Transport Group framework as the
   solution for the problems and specifies a set of requirements for
   Composite Transport Group(CTG).


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Conventions used in this document  . . . . . . . . . . . . . .  4
     2.1.  Acronyms . . . . . . . . . . . . . . . . . . . . . . . . .  4
   3.  Problem Statements . . . . . . . . . . . . . . . . . . . . . .  5
     3.1.  Incomplete/Inefficient Utilization . . . . . . . . . . . .  5
     3.2.  Inefficiency/Inflexibility of Logical Interface
           Bandwidth Allocation . . . . . . . . . . . . . . . . . . .  6
   4.  Composite Transport Group Framework  . . . . . . . . . . . . .  8
     4.1.  CTG Framework  . . . . . . . . . . . . . . . . . . . . . .  8
     4.2.  Difference between CTG and A Bundled Link  . . . . . . . . 10
       4.2.1.  Virtual Routable Link vs. TE Link  . . . . . . . . . . 10
       4.2.2.  Component Link Parameter Independence  . . . . . . . . 11
   5.  Composite Transport Group Requirements . . . . . . . . . . . . 12
     5.1.  CTG Appearance as a Routable Virtual Interface . . . . . . 12
     5.2.  CTG mapping of traffic to Component Links  . . . . . . . . 12
       5.2.1.  Mapping Using Router TE information  . . . . . . . . . 12
       5.2.2.  Mapping When No Router TE Information is Available . . 12
     5.3.  Bandwidth Control for Connections with and without TE
           information  . . . . . . . . . . . . . . . . . . . . . . . 13
     5.4.  CTG Transport Resilience . . . . . . . . . . . . . . . . . 14
   6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 15
   7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 16
   8.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17
   9.  Normative References . . . . . . . . . . . . . . . . . . . . . 18
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19
   Intellectual Property and Copyright Statements . . . . . . . . . . 20














So, et al.               Expires April 24, 2009                 [Page 2]

Internet-Draft       CTG framework and requirements         October 2008


1.  Introduction

   IP/MPLS network traffic growth forces carriers to deploy multiple
   parallel physical links between two routers.  The network is also
   expected to carry some flows of a rate that can approach that of any
   single link or be very small comparing to a single link rate.  There
   is not an existing technology today that allows carriers to
   efficiently utilize all parallel transport resources in a complex IP/
   MPLS network environment.  Composite Transport Group (CTG) provides
   the local traffic engineering management over multiple parallel links
   that solves this problem in MPLS networks.

   The primary function of Composite Transport Group is to efficiently
   transport aggregated traffic flows over multiple parallel links.  CTG
   can take the flow TE information into account when distributing the
   flows over individual links to gain local traffic engineering
   management and link failure protection.  Because all links have the
   same ingress and egress point, CTG does not need to perform route
   computation and forwarding based on the traffic unit end point
   information, which brings a unique local transport traffic
   engineering scheme.  CTG also manages the flows that do not have TE
   information and associates them with CTG connections that have
   assigned TE information based on auto bandwidth measurement, and use
   the TE information in component link selection.

   This document contains the problem statements and the framework and a
   set of requirements for a Composite Transport Group (CTG).  The
   necessity for protcol extensions to provide solutions is for future
   study.






















So, et al.               Expires April 24, 2009                 [Page 3]

Internet-Draft       CTG framework and requirements         October 2008


2.  Conventions used in this document

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].

2.1.  Acronyms

   BW: BandWidth

   CTG: Composite Transport Group

   ECMP: Equal Cost Multi-Path

   FRR: Fast Re-Route

   LAG: Link Aggregation Group

   LDP: Label Distributed Protocol

   LR: Logical Router

   LSP: Label Switched Path

   MPLS: Multi-Protocol Label Switch

   OAM: Operation, Administration, and Maintenance

   PDU: Packet Data Units

   PE: Provider Edge device

   RSVP: ReSource reserVation Protocol

   RTD: Real Time Delay

   TE: Traffic engineering

   VRF: Virtual Routing & Forwarding












So, et al.               Expires April 24, 2009                 [Page 4]

Internet-Draft       CTG framework and requirements         October 2008


3.  Problem Statements

   Two applications are described here that encounter the problems when
   multiple parallel links are deployed between two routers in today's
   IP/MPLS networks.

3.1.  Incomplete/Inefficient Utilization

   An MPLS-TE network is deployed to carry traffic on RSVP-TE LSPs, i.e.
   traffic engineered flows.  When traffic volume exceeds the capacity
   of a single physical link, multiple physical links are deployed
   between two routers as a single backbone trunk.  How to assign LSP
   traffic over multiple links and maintain this backbone trunk as a
   higher capacity and higher availability trunk than a single physical
   link becomes an extremely difficult task for carriers today.  Three
   methods that are available today are described here.

   1.  A hashing method is a common practice for traffic distribution
       over multiple paths.  This is used by Equal Cost Multi-Path
       (ECMP) for IP services, and IEEE-defined Link Aggregation Group
       (LAG) for Ethernet traffic.  However, the traffic granularity in
       a MPLS-TE network is individual LSPs, and they typically contain
       a high rate of traffic flow(s) and have large differences in the
       rates; furthermore, the links may be of different speeds.  In
       these cases hashing can cause some links to be congested while
       others are partially filled because hashing can only distinguish
       the flows, not the flow rates.

   2.  Assigning individual LSPs to each link through constrained
       routing.  A planning tool can track the utilization of each link
       and assignment of LSPs to the links.  To gain high availability,
       FRR [RFC4090] is used to create a bypass tunnel on a link to
       protect traffic on another link or to create a detour LSP to
       protect another LSP.  If reserving BW for the bypass tunnels or
       the detour LSPs, the network will reserve a large amount of
       capacity for failure recovery, which reduces the capacity to
       carry other traffic.  If not reserving BW for the bypass tunnels
       and the detour LSPs, the planning tool can not assign LSPs
       properly to avoid the congestion during link failure when there
       are more than two parallel links.  This is because during the
       link failure, the impacted traffic is simply put on a bypass
       tunnel or detour LSPs which does not have enough reserved
       bandwidth to carry the extra traffic during the failure recovery
       phase.

   3.  Facility protection, also called 1:1 protection.  Dedicate one
       link to protect another link.  Only assign traffic to one link in
       the normal condition.  When the working link fails, switch



So, et al.               Expires April 24, 2009                 [Page 5]

Internet-Draft       CTG framework and requirements         October 2008


       traffic to the protected link.  This requires 50% capacity for
       failure recovery.  This works when there are only two links.
       Under the multiple parallel link condition, this causes
       inefficient use of network capacity because there is no
       protection capacity sharing.  In addition, due to traffic
       burstiness, having one link fully loaded and another link idle
       increases transport latency and packet loss, which lowers the
       link performance quality for transport.

   None of these methods satisfies carrier requirement either because of
   poor link utilization or poor performance.  This forces carriers to
   go with the solution of deploying single higher capacity link
   solution.  However, a higher capacity link can be expensive as
   compared with parallel low capacity links of equivalent aggregate
   capacity; a high capacity link can not be deployed in some
   circumstances due to physical impairments; or the highest capacity
   link may not large enough for some carriers.

   An LDP network can encounter the same issue as an MPLS-TE enabled
   network when multiple parallel links are deployed as a backbone
   trunk.  An LDP network can have large variance in flow rates where,
   for example, the small flows may be carrying stock tickers at a few
   kbps per flow while the large flows can be near 10 Gbps per flow
   carrying machine to machine and server to server traffic from
   individual customers.  Those large traffic flows often cannot be
   broken into micro flows.  Therefore, hashing would not work well for
   the networks carrying such flows.  Without per-flow TE information,
   this type of network has even more difficulty to use multiple
   parallel links and keep high link utilization.

3.2.  Inefficiency/Inflexibility of Logical Interface Bandwidth
      Allocation

   Logically-separate routing instances in some implementations further
   complicates the situation.  Dedicating separate physical backbone
   links to each routing instance is not efficient.  An alternative is
   to assign a logical interface and bandwidth on each of the parallel
   physical links to each routing instance, which improves efficiency as
   compared with dedicating physical links to each routing instance.
   Inefficiency can result if bandwidth on a logical interface is
   dedicated to each routing instance.  For example, if there are 2
   routing instances and 3 parallel links and half of each link
   bandwidth is assigned to a routing instance, then neither routing
   instance can support an LSP with bandwidth greater than half the link
   bandwidth.

   Note that the traffic flows and LSPs from these different routing
   instances effectively operate in a Ships-in-the-Night mode, where



So, et al.               Expires April 24, 2009                 [Page 6]

Internet-Draft       CTG framework and requirements         October 2008


   they are unaware of each other.  Inflexibility results if there are
   multiple sets of LSPs (e.g., from different routing instances)
   sharing a set of parallel links, and at least one set of LSPs can
   preempt another, then more efficient sharing of the link set between
   the routing instances is highly desirable.














































So, et al.               Expires April 24, 2009                 [Page 7]

Internet-Draft       CTG framework and requirements         October 2008


4.  Composite Transport Group Framework

4.1.  CTG Framework

   Composite Transport Group (CTG) is the method to transport aggregated
   traffic over a composite link.  A composite link defined in ITU-T
   [ITU-T G.800] is a single link that bundles multiple parallel links
   between the two same subnetworks.  Each of component links of a
   composite link is independent in the sense that each component link
   is supported by a separate server layer trail.  The composite link
   conveys communication information using different server layer trails
   thus the sequence of symbols across this link may not be preserved.

   Composite Transport Group (CTG) is primarily a local traffic
   engineering and transport technology over multiple parallel links or
   multiple paths.  The objective is for a composite link to appear as a
   virtual interface to the connected routers.  The router provisions
   incoming traffic over the CTG connection.  CTG connections are
   transported over parallel links called Component Links.  CTG
   Component Links can be either physical links or logical links such as
   LSP tunnels.  The CTG distribution function can locally determine
   which component link CTG connections should traverse.  The major
   components of CTG and their relationships are illustrated in Figure 1
   below.




                +---------+                            +-----------+
                |     +---+                            +---+       |
                |     |   |============================|   |       |
      LSP,LDP,IP|     | C |~~~~~~5 CTG Connections ~~~~| C |       |
             ~~~|~~>~~|   |============================|   |~~~>~~~|~~~
             ~~~|~~>~~| T |============================| T |~~~>~~~|~~~
             ~~~|~~>~~|   |~~~~~~3 CTG Connections ~~~~|   |~~~>~~~|~~~
                |     | G |============================| G |       |
                |     |   |============================|   |       |
                |     |   |~~~~~~9 CTG connections~~~~~|   |       |
                |     |   |============================|   |       |
                | R1  +---+                            +---+    R2 |
                +---------+                            +-----------+
                      !   !                            !   !
                      !   !<----Component Links ------>!   !
                      !<------ Composite Link  ----------->!



          Figure 1: Composite Transport Group Architecture Model



So, et al.               Expires April 24, 2009                 [Page 8]

Internet-Draft       CTG framework and requirements         October 2008


   In Figure 1, a composite link is configured between router R1 and R2.
   The composite link has three component links.  CTG creates a CTG
   connection and select a component link for the CTG connection.  LSP,
   LDP, and IP traffic are mapped to CTG connections.  A CTG connection
   only exists in the scope of a composite link.  The traffic in a CTG
   connection is transported over a single component link.

   A CTG connection is a point-to-point logical connection over a
   composite link.  The connection rides on component link in a one-to-
   one or many-to-one relationship.  LSPs map to CTG connections in a
   one-to-one or many-to-one relationship.  The connection can have the
   following traffic engineering parameters:

   o  bandwidth over-subscription

   o  factor placement

   o  priority

   o  holding priority

   CTG connection TE parameters can be mapped directly from the LSP
   parameters signaled in RSVP-TE or can be set at the CTG management
   interface (CTG Logical Port).  The connection bandwidth MUST be set.
   If a LSP has no bandwidth information, the bandwidth will be
   calculated at CTG ingress using automatic bandwidth measurement
   function.

   LDP LSPs can be mapped onto the connections per LDP label.  Both
   outer label (PE-PE label) and Inner label (VRF Label) can be used for
   the connection mapping.  CTG connection bandwidth MUST be set through
   auto-bandwidth measurement function at the CTG ingress.  When the
   connection bandwidth tends to exceed the component link capacity, CTG
   is able to reassign the flows in one connection into several
   connections and assign other component links for the connections
   without traffic disruption.

   A CTG component link can be a physical link or logical link (LSP
   Tunnel) between two routers.  When component links are physical
   links, there is no restriction to component link type, bandwidth, and
   performance objectives (e.g., RTD and Jitter).  Each component link
   MUST maintain its own OAM.  CTG is able to get component link status
   from each link and take an action upon component link status changes.

   Each component link can have its own Component Link Cost and
   Component Link Bandwidth as its associated engineered parameters.
   CTG uses component link parameters in the assignment of CTG
   connections to component links.



So, et al.               Expires April 24, 2009                 [Page 9]

Internet-Draft       CTG framework and requirements         October 2008


   CTG provides local traffic engineering management over parallel links
   based on CTG connection TE information and component link parameters.
   Component link selection for CTG connections is determined locally
   and may change without reconfiguring the traffic flows.  Changing the
   selection may be triggered by a component link condition change, a
   new traffic flow configured or existing one modified, or operator
   required optimization process.  CTG component link selection for CTG
   connections enables TE based traffic distribution and link failure
   recovery with much less link capacity than current methods mentioned
   in the section of the problem statements.

   CTG connections are created for traffic management purpose on a
   composite link.  They do not change the forwarding schema.  The
   forwarding engine still forwards based on the LSP label created per
   traffic LSP.  Therefore, there is no change to the forwarding.

   Since MPLS is built on the top of IP network, some IP PDUs are
   carried over the MPLS network.  CTG may designate one CTG connection
   for such traffic or use hashing to distribute IP PDUs over component
   links.  The assumption is that such traffic volume is very small
   compared to LSP or LDP traffic.

   CTG techniques applies to the situation that the rate of the distinct
   traffic flows are not higher than component link capacity in CTG.

4.2.  Difference between CTG and A Bundled Link

4.2.1.   Virtual Routable Link vs. TE Link

   CTG is a data plan transport function over a composite link.  A
   composite link contains multiple component links that can carry
   traffic independently.  CTG is the method to transport aggregated
   traffic over a composite link.  The composite link appears as a
   single routable virtual interface between the connected routers.  The
   network only maps LSP or LDP to a composite link, i.e. not to
   individual component links.  CTG will select component link for
   individual LSP and LDP and merge them at composite link egress.

   A bundled link [RFC4201] is a collection of TE links.  It is a
   logical construct that represents a way to group/map the information
   about certain physical resources that interconnect routers.  The
   purpose of bundled link is to improve routing scalability by reducing
   the amount of information that has to be handled by OSPF/IS-IS.  Each
   physical links in the bundled link are an IGP link in OSPF/IS-IS.  A
   bundled link only has the significance to router control plane.  The
   router has to map individual LSP to each component link in the
   bundled link, which is different from CTG.  A bundled link only
   applies to RSVP-TE signaled traffic.



So, et al.               Expires April 24, 2009                [Page 10]

Internet-Draft       CTG framework and requirements         October 2008


4.2.2.   Component Link Parameter Independence

   CTG allows component links to have different costs, traffic
   engineering metric and resource classes.  CTG can derive the virtual
   interface cost from component link costs based on operator policy.
   CTG can derive the traffic engineering parameter for a virtual
   interface from its component link traffic engineering parameters.

   However, a bundled link [RFC4201] requires that all component links
   in a bundle to have the same traffic engineering metric, and the same
   set of resource classes.








































So, et al.               Expires April 24, 2009                [Page 11]

Internet-Draft       CTG framework and requirements         October 2008


5.  Composite Transport Group Requirements

   Composite Transport Group (CTG) is about the method to transport
   aggregated traffic over multiple parallel links.  CTG can address the
   problems existing in today IP/MPLS network.  Here are some CTG
   requirements:

5.1.  CTG Appearance as a Routable Virtual Interface

   The carrier needs a solution where multiple routing instances see a
   separate "virtual interface" to a shared composite transport group
   composed of parallel physical links between a pair of routers.

   The CTG would communicate parameters (e.g., admin cost, available
   bandwidth, maximum bandwidth, allowable bandwidth) for the "virtual
   interface" associated with each routing instance.

   The "virtual interface" shall appear as a fully-featured IP adjacency
   to each routing instance, not just an FA [RFC3477] .  In particular,
   it needs to work with at least the following IP/MPLS control
   protocols: IGP, LDP, IGP-TE, and RSVP-TE.

5.2.  CTG mapping of traffic to Component Links

   The objective of CTG is to solve the traffic sharing problem at a
   virtual interface level by mapping traffic to component links (not
   using hashing):

   1.  using TE information from the control planes of the routing
       instances attached to the virtual interface when available, or

   2.  using traffic measurements when it is not.

5.2.1.  Mapping Using Router TE information

   CTG SHALL use RSVP-TE for bandwidth signaled by a routing instance to
   explicitly assign a TE LSPs to CTG connection that is assigned to a
   specific link in the CTG.

   The CTG SHALL be able to receive, interpret and act upon at least the
   following router signaled parameters: minimum bandwidth, maximum
   bandwidth, preemption priority, and holding priority and apply them
   to CTG connections where the LSP is mapped.

5.2.2.  Mapping When No Router TE Information is Available

   CTG SHALL map LDP-assigned labeled packets based upon local
   configuration (e.g., label stack depth) to define a CTG connection



So, et al.               Expires April 24, 2009                [Page 12]

Internet-Draft       CTG framework and requirements         October 2008


   that is mapped to one of the parallel links in the CTG between
   routers.

   CTG SHALL map LDP-assigned labeled packets that identify the source-
   destination LER as a CTG connection to a specific link in the CTG.

   CTG SHALL also handle IP traffic without MPLS labels.  This could use
   locally defined methods to assign sets of IP traffic to a CTG
   connection.

   In all of the above mapping cases, CTG SHALL place an entire
   connection onto a single physical link.

   In a mapping case, the CTG SHALL measure the bandwidth actually used
   by a particular connection to determine which component link
   (physical link) on the CTG that CTG connection should be transmitted.

   The CTG SHALL support parameters that control the time period between
   moving a CTG connection from one link to another since this could
   cause reordering.

   The CTG SHALL support parameters that define at least a minimum
   bandwidth, maximum bandwidth, preemption priority, and holding
   priority for connections without TE information.

5.3.  Bandwidth Control for Connections with and without TE information

   The following requirements apply to a virtual interface (i.e.,
   composite link in section 4) that supports connections with TE
   information in conjunction with connections that do not have TE
   information.

   A "bandwidth shortage" issue can arise in CTG if the total bandwidth
   of the connections with TE information and those without TE
   information exceeds the bandwidth of the composite link.

   The CTG SHALL support a policy based preemption capability such that
   in the event of such a "bandwidth shortage" that the signaled or
   configured preemption and holding parameters can be applied to the
   following treatments to the connections:

   o  For a connection that has RSVP-TE LSP(s), signal the router that
      the TE-LSP has been preempted.

   o  For a connection that has LDP(s), where the CTG is aware of the
      LDP signaling involved to the preempted label stack depth, signal
      release of the label to the router




So, et al.               Expires April 24, 2009                [Page 13]

Internet-Draft       CTG framework and requirements         October 2008


   o  For a connection that has IP traffic without MPLS labels, indicate
      congestion to the router (e.g., using ECN, PCN, or some local
      method) or block IP traffic.

5.4.  CTG Transport Resilience

   Component link in CTG can fail independently.  The failure of
   component link can impact some CTG connections.  The impacted CTG
   connection SHALL be placed to other active component links by using
   the same rules as of component link section for CTG connections.









































So, et al.               Expires April 24, 2009                [Page 14]

Internet-Draft       CTG framework and requirements         October 2008


6.  Security Considerations

   CTG is a local function on the router to support traffic engineering
   management over multiple parallel links.  It does not introduce a
   security risk for control plane and dada plane.














































So, et al.               Expires April 24, 2009                [Page 15]

Internet-Draft       CTG framework and requirements         October 2008


7.  IANA Considerations

   There is no IANA actions requested in this specification.
















































So, et al.               Expires April 24, 2009                [Page 16]

Internet-Draft       CTG framework and requirements         October 2008


8.  Acknowledgements

   Authors would like to thank Frederic Jounay from France Telecom,
   Adrian Farrel from Olddog, and Ron Bonica from Juniper for 
   the review and great suggestions.















































So, et al.               Expires April 24, 2009                [Page 17]

Internet-Draft       CTG framework and requirements         October 2008


9.  Normative References

   [ITU-T G.800]
              ITU-T Q12, "Unified Functional Architecture of Transport
              Network", ITU-T G.800, February 2008.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement  Levels", RFC 2119, March 1997.

   [RFC3477]  Kompella, K., "Signalling Unnumbered Links in Resource
              ReSerVation Protocol - Traffic Engineering (RSVP-TE)",
              RFC 3477, January 2003.

   [RFC4090]  Pan, P., "Fast Reroute Extensions to RSVP-TE for LSP
              Tunnels", RFC 4090, May 2005.

   [RFC4201]  Kompella, K., "Link Bundle in MPLS Traffic Engineering",
              RFC 4201, March 2005.

































So, et al.               Expires April 24, 2009                [Page 18]

Internet-Draft       CTG framework and requirements         October 2008


Authors' Addresses

   So Ning
   Verizon
   2400 N. Glem Ave.,
   Richerson, TX  75082

   Phone: +1 972-729-7905
   Email: ning.so@verizonbusness.com


   Andrew Malis
   Verizon
   117 West St.
   Waltham, MA  02451

   Phone: +1 781-466-2362
   Email: andrew.g.malis@verizon.com


   Dave McDysan
   Verizon
   22001 Loudoun County PKWY
   Ashburn, VA  20147

   Phone: +1 707-886-1891
   Email: dave.mcdysan@verizon.com


   Lucy Yong
   Huawei USA
   1700 Alma Dr. Suite 500
   Plano, TX  75075

   Phone: +1 469-229-5387
   Email: lucyyong@huawei.com















So, et al.               Expires April 24, 2009                [Page 19]

Internet-Draft       CTG framework and requirements         October 2008


Full Copyright Statement

   Copyright (C) The IETF Trust (2008).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.











So, et al.               Expires April 24, 2009                [Page 20]