doc: Add RFC documents

1 files changed, 675 insertions, 0 deletions

diff --git a/doc/rfc/rfc6512.txt b/doc/rfc/rfc6512.txt
new file mode 100644
index 0000000..a624afc
--- /dev/null
+++ b/doc/rfc/rfc6512.txt
@@ -0,0 +1,675 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF)                      IJ. Wijnands
+Request for Comments: 6512                                      E. Rosen
+Category: Standards Track                                  Cisco Systems
+ISSN: 2070-1721                                             M. Napierala
+                                                                    AT&T
+                                                              N. Leymann
+                                                        Deutsche Telekom
+                                                           February 2012
+
+
+    Using Multipoint LDP When the Backbone Has No Route to the Root
+
+Abstract
+
+   The control protocol used for constructing Point-to-Multipoint and
+   Multipoint-to-Multipoint Label Switched Paths ("MP LSPs") contains a
+   field that identifies the address of a "root node".  Intermediate
+   nodes are expected to be able to look up that address in their
+   routing tables.  However, this is not possible if the route to the
+   root node is a BGP route and the intermediate nodes are part of a
+   BGP-free core.  This document specifies procedures that enable an MP
+   LSP to be constructed through a BGP-free core.  In these procedures,
+   the root node address is temporarily replaced by an address that is
+   known to the intermediate nodes and is on the path to the true root
+   node.
+
+Status of This Memo
+
+   This is an Internet Standards Track document.
+
+   This document is a product of the Internet Engineering Task Force
+   (IETF).  It represents the consensus of the IETF community.  It has
+   received public review and has been approved for publication by the
+   Internet Engineering Steering Group (IESG).  Further information on
+   Internet Standards is available in Section 2 of RFC 5741.
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   http://www.rfc-editor.org/info/rfc6512.
+
+Copyright Notice
+
+   Copyright (c) 2012 IETF Trust and the persons identified as the
+   document authors.  All rights reserved.
+
+   This document is subject to BCP 78 and the IETF Trust's Legal
+   Provisions Relating to IETF Documents
+   (http://trustee.ietf.org/license-info) in effect on the date of
+
+
+
+Wijnands, et al.             Standards Track                    [Page 1]
+
+RFC 6512         Using mLDP with Recursive Opaque Values   February 2012
+
+
+   publication of this document.  Please review these documents
+   carefully, as they describe your rights and restrictions with respect
+   to this document.  Code Components extracted from this document must
+   include Simplified BSD License text as described in Section 4.e of
+   the Trust Legal Provisions and are provided without warranty as
+   described in the Simplified BSD License.
+
+Table of Contents
+
+   1. Introduction ....................................................3
+   2. The Recursive Opaque Value ......................................5
+      2.1. Encoding ...................................................5
+      2.2. Procedures .................................................5
+   3. The VPN-Recursive Opaque Value ..................................6
+      3.1. Encoding ...................................................6
+      3.2. Procedures .................................................7
+           3.2.1. Non-Segmented Inter-AS P-Tunnels ....................7
+           3.2.2. Limited Carrier's Carrier Function ..................9
+   4. IANA Considerations ............................................10
+   5. Security Considerations ........................................10
+   6. Acknowledgments ................................................10
+   7. References .....................................................11
+      7.1. Normative References ......................................11
+      7.2. Informative References ....................................11
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Wijnands, et al.             Standards Track                    [Page 2]
+
+RFC 6512         Using mLDP with Recursive Opaque Values   February 2012
+
+
+1.  Introduction
+
+   The document [mLDP] extends LDP [LDP] to support multipoint Label
+   Switched Paths.  These extensions are known as "Multipoint LDP", or
+   more simply, as "mLDP".  [mLDP] defines several LDP Forwarding
+   Equivalence Class (FEC) element encodings: "Point-to-Multipoint"
+   (P2MP), "Multipoint-to-Multipoint (MP2MP) Upstream", and "MP2MP
+   Downstream".
+
+   The encoding for these three FEC elements, as defined in [mLDP], is
+   shown in Figure 1.
+
+       0                   1                   2                   3
+       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |     Type      |        Address Family         | Address Length|
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      ~                       Root Node Address                       ~
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |    Opaque Length              |                               |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
+      ~                                                               ~
+      |                     Opaque Value                              |
+      |                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                               |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+                   Figure 1: mLDP FEC Element Encoding
+
+   Note that a P2MP or MP2MP Label Switched Path ("MP LSP") is
+   identified by the combination of a "root node" and a variable length
+   "opaque value".  The root node also plays a special role in the mLDP
+   procedures:  mLDP messages that are "about" a particular MP LSP are
+   forwarded to the LDP adjacency that is the next hop on the route to
+   the root node.
+
+   Sometimes, it is desirable for an MP LSP to pass through a part of
+   the network in which there is no route to the root node.  For
+   instance, consider the topology of Figure 2.
+
+           CE1----PE1---P1---- ...----P2 ----PE2----CE2----R
+
+                                Figure 2
+
+   In Figure 2, CE1 and CE2 are "Customer Edge routers", R is a customer
+   router at the same VPN site as CE2, and PE1 and PE2 are "Provider
+   Edge routers".  Suppose that PE1 has a BGP-learned route for R, with
+
+
+
+
+Wijnands, et al.             Standards Track                    [Page 3]
+
+RFC 6512         Using mLDP with Recursive Opaque Values   February 2012
+
+
+   PE2 as the BGP next hop.  Suppose also that the provider's interior
+   routers (such as P1 and P2) do not have any BGP-learned routes and,
+   in particular, do not have any routes to R.
+
+   In such an environment, unicast data packets from CE1 addressed to R
+   would get encapsulated by PE1, tunneled to PE2, decapsulated by PE2,
+   and forwarded to CE2.
+
+   Suppose now that CE1 is trying to set up an MP LSP whose root is R,
+   and the intention is that the provider's network will participate in
+   the construction of the LSP.  Then, the mLDP messages identifying the
+   LSP must be passed from CE1 to PE1, from PE1 to P1, ..., from P2 to
+   PE2, from PE2 to CE2, and from CE2 to R.
+
+   To begin the process, CE1 creates an MP FEC element with the address
+   of R as the root node address and passes that FEC element via mLDP to
+   PE1.  However, PE1 cannot use this same FEC element to identify the
+   LSP in the LDP messages it sends to P1, because P1 does not have a
+   route to R.
+
+   However, PE1 does know that PE2 is the BGP next hop on the path to R.
+   What is needed is a method whereby:
+
+   -  PE1 can tell P1 to set up an LSP as if the root node were PE2,
+
+   -  PE2 can determine that the LSP in question is really rooted at R,
+      not at PE2 itself, and
+
+   -  PE2 can determine the original FEC element that CE1 passed to PE1,
+      so that PE2 can pass it on to CE2.
+
+   This document defines the procedures that allow CE1 to create an LSP
+   rooted at R.  These procedures require PE1 to modify the MP FEC
+   element before sending an mLDP message to P1.  The modified FEC
+   element has PE2 as the root and the original FEC element as the
+   opaque value.  This requires a new type of opaque value.  Since the
+   opaque value contains a FEC element, we call this a "Recursive Opaque
+   Value".  When PE2 sends an mLDP message to CE2, it replaces the FEC
+   element with the opaque value, thus undoing the recursion.  Details
+   are in Section 2.
+
+   Section 3 defines the "VPN-Recursive Opaque Value".  Whereas the
+   "Recursive Opaque Value" carries the original FEC, the "VPN-Recursive
+   Opaque Value" carries the original FEC plus a Route Distinguisher
+   (RD).  This is applicable when MP LSPs are being used to carry the
+   multicast traffic of a VPN [MVPN].  Details are in Section 3.
+
+
+
+
+
+Wijnands, et al.             Standards Track                    [Page 4]
+
+RFC 6512         Using mLDP with Recursive Opaque Values   February 2012
+
+
+   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.  The Recursive Opaque Value
+
+2.1.  Encoding
+
+   We define a new type of opaque value, the Recursive Opaque Value.
+   This is a "basic type", identified by a 1-octet type field.
+
+       0                   1                   2                   3
+       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+       |  Type = 7     |         Length                |               |
+       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+               |
+       ~                                                               ~
+       |                 P2MP or MP2MP FEC Element                     |
+       |                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+       |                               |
+       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+                      Figure 3: Recursive Opaque Value
+
+   The value field of the Recursive Opaque Value is itself a P2MP or
+   MP2MP FEC element, encoded exactly as specified in [mLDP], with a
+   type field, a length field, and value field of its own.  The length
+   of the Recursive Opaque Value thus includes the lengths of the type,
+   length, and value fields of the contained FEC element.
+
+2.2.  Procedures
+
+   In the topology of Figure 2, let us suppose that CE1 sends PE1 an MP
+   FEC element whose root node is R and whose opaque value is Q.  We
+   will refer to this FEC element as "CE1-FEC".  We may think of CE1-FEC
+   as an ordered pair, as follows:
+
+       CE1-FEC = <root=R, opaque_value=Q>.
+
+   PE1 determines that the root node R matches a BGP route, with a BGP
+   next hop of PE2.  PE1 also knows by its configuration that the
+   interior routers on the path to PE2 are "BGP-free" and thus have no
+   route to R.
+
+   PE1 therefore creates a new MP FEC element, whose root node address
+   is the address of PE2 and whose opaque value is a Recursive Opaque
+   Value whose value field contains CE1-FEC.  We refer to this FEC
+   element as PE2-FEC:
+
+
+
+Wijnands, et al.             Standards Track                    [Page 5]
+
+RFC 6512         Using mLDP with Recursive Opaque Values   February 2012
+
+
+       PE2-FEC = <root=PE2, opaque_value=CE1-FEC>, i.e.,
+
+       PE2-FEC = <root=PE2, opaque_value=<root=R,
+                                          opaque_value=Q>>
+
+   PE1 then sends this FEC element to P1.
+
+   As far as the interior routers are concerned, they are being
+   requested to build an MP LSP whose root node is PE2.  They MUST NOT
+   interpret the opaque value at all.
+
+   When PE2-FEC arrives at PE2, PE2 notes that it (PE2) is the
+   identified root node and that the opaque value is a Recursive Opaque
+   Value.  Therefore, PE2 MUST replace PE2-FEC with the contents of the
+   Recursive Opaque Value (i.e., with CE1-FEC) before doing any further
+   processing.  This will result in CE1-FEC being sent on to CE2, and
+   further from CE2 to R.  Note that CE1-FEC will contain the LSP root
+   node specified by CE1; the presumption is that PE2 has a route to
+   this root node.
+
+3.  The VPN-Recursive Opaque Value
+
+3.1.  Encoding
+
+   We define a new type of opaque value, the VPN-Recursive Opaque Value.
+   This is a "basic type", identified by a 1-octet type field.
+
+       0                   1                   2                   3
+       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+       |  Type = 8     |         Length                |               |
+       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+               |
+       |                                                               |
+       |       Route Distinguisher (8 octets)          +-+-+-+-+-+-+-+-+
+       |                                               |               |
+       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+               |
+       ~                                                               ~
+       |                 P2MP or MP2MP FEC Element                     |
+       |                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+       |                               |
+       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+                      Figure 4: VPN-Recursive Opaque Value
+
+
+
+
+
+
+
+
+Wijnands, et al.             Standards Track                    [Page 6]
+
+RFC 6512         Using mLDP with Recursive Opaque Values   February 2012
+
+
+   The value field of the VPN-Recursive Opaque Value consists of an
+   8-octet Route Distinguisher (RD), followed by a P2MP or MP2MP FEC
+   element, encoded exactly as specified in [mLDP], with a type field, a
+   length field, and value field of is own.  The length of the
+   VPN-Recursive Opaque Value thus includes the 8 octets of RD plus the
+
+   lengths of the type, length, and values fields of the contained FEC
+   element.
+
+3.2.  Procedures
+
+3.2.1.  Non-Segmented Inter-AS P-Tunnels
+
+   Consider the inter-AS (Autonomous System) VPN scenario depicted in
+   Figure 5.
+
+           PE1 --- P1 ---- ASBR1 ... ASBR2 ---- P2 ---- PE2
+
+                                Figure 5
+
+   Suppose this is an "option B" VPN interconnect ([VPN], Section 10).
+   This means that the Autonomous System Border Router (ASBR) in the
+   first Autonomous System (i.e., ASBR1) does not have a route to PE
+   routers in other ASes (such as PE2).  Suppose also that the Multicast
+   VPN (MVPN) policy is to instantiate Provider Multicast Service
+   Interfaces (PMSIs) [MVPN] using mLDP and that "non-segmented inter-AS
+   P-tunnels" [MVPN] are being used.
+
+   In this scenario, PE1 may need to join a P2MP or MP2MP LSP whose root
+   is PE2.  P1 has no route to PE2, and all PE1 knows about the route to
+   PE2 is that ASBR1 is the BGP next hop.  Since P1 has no root to PE2,
+   PE1 needs to originate an mLDP message with a FEC element that
+   identifies ASBR1 as the root.  This FEC element must contain enough
+   information to enable ASBR1 to find the next hop towards PE2 even
+   though ASBR1 does not have a route to PE2.
+
+   Although ASBR1 does not have a route to PE2, it does have a BGP
+   Intra-AS Inclusive PMSI (I-PMSI) auto-discovery (A-D) route [MVPN]
+   whose Network Layer Reachability Information (NLRI) contains PE2's IP
+   address together with a particular RD.  PE1 also has this Inter-AS
+   I-PMSI A-D route.  The LSP needs to be set up along the path
+   established by the Intra-AS I-PMSI A-D routes.  Therefore, one must
+   use a Recursive FEC element that contains the RD as well as the
+   address of PE2.  The "VPN-Recursive FEC Element" defined herein is
+   used for this purpose.
+
+
+
+
+
+
+Wijnands, et al.             Standards Track                    [Page 7]
+
+RFC 6512         Using mLDP with Recursive Opaque Values   February 2012
+
+
+   This enables us to provide the same functionality for mLDP P-tunnels
+   that is provided for PIM P-tunnels in Section 8.1.3.2 of [MVPN]
+   through the use of the MVPN Join Attribute.
+
+   At PE1 in Figure 4, the LSP to be created is associated with a
+   particular VPN Routing and Forwarding Table (VRF).  PE1 looks up in
+   that VRF the Intra-AS I-PMSI A-D route originated by PE2.  It finds
+   that the BGP next hop of that route is ASBR1.  So, it creates a P2MP
+   or MP2MP FEC element whose root is ASBR1 and whose opaque value is a
+   VPN-Recursive FEC element.  The VPN-Recursive FEC element itself
+   consists of a root, an RD, and an opaque value, set as follows:
+
+   -  The root is PE2.
+
+   -  The RD is the RD from the NLRI of the Intra-AS A-D route
+      originated by PE2.
+
+   -  The opaque value is chosen (by some method outside the scope of
+      this document) so as to be unique in the context of PE2.  (For
+      example, it may have been specified in a PMSI Tunnel Attribute
+      originated by PE2.)  We will refer to this opaque value as "Q".
+
+   The resulting FEC element can be informally represented as
+
+       <root=ASBR1, opaque_value=<root=PE2, RD, opaque_value=Q>>.
+
+   PE1 can now begin setting up the LSP by using this FEC element in an
+   LDP Label Mapping message sent towards ASBR1.
+
+   When ASBR1 receives, over a non-VRF interface, an mLDP Label Mapping
+   message containing this FEC element, it sees that it is the root and
+   that the opaque value is a VPN-Recursive Opaque Value.  It parses the
+   VPN-Recursive Opaque value and extracts the root value, PE2.
+
+   If ASBR1 has a route to PE2, it continues setting up the LSP by using
+   the following FEC element:
+
+       <root=PE2, opaque_value=Q>
+
+   However, if ASBR1 does not have a route to PE2, it looks for an
+   Intra-AS I-PMSI A-D route whose NLRI contains PE2's address along
+   with the specified RD value.  Say the BGP next hop of that route is
+   ASBR2.  Then ASBR1 continues setting up the LSP by using the
+   following FEC element:
+
+       <root=ASBR2, opaque_value=<root=PE2, RD, opaque_value=Q>>.
+
+
+
+
+
+Wijnands, et al.             Standards Track                    [Page 8]
+
+RFC 6512         Using mLDP with Recursive Opaque Values   February 2012
+
+
+   Note that in this case, the root has changed from ASBR1 to ASBR2, but
+   the opaque value is the unchanged VPN-Recursive FEC element.
+
+3.2.2.  Limited Carrier's Carrier Function
+
+   Another possible use of the VPN-Recursive FEC is to provide a limited
+   version of "Carrier's Carrier Service".  Referring again to the
+   topology of Figure 2, suppose that PE1/PE2 are offering "Carrier's
+   Carrier VPN Service" [VPN] to CE1/CE2.  CE1 sends PE1 an MP FEC
+   element whose root node is R and whose opaque value is Q.  We will
+   refer to this FEC element as "CE1-FEC".  However, PE1's route to R
+   will be in a VRF.  Therefore, the FEC element created by PE1 must
+   contain some identifier that PE2 can use to find the proper VRF in
+   which to look up the address of R.
+
+   When PE1 looks up the address of R in a VRF, it will find a route in
+   the VPN-IP address family.  The next hop will be PE2, but there will
+   also be a Route Distinguisher (RD) as part of that NLRI of the
+   matching route.  In this case, the new FEC element created by PE1 has
+   the address of PE2 as the root node address and has a VPN-Recursive
+   Opaque Value.  The value field of the VPN-Recursive Opaque Value
+   consists of the 8-octet RD followed by CE1-FEC.
+
+   As far as the interior routers are concerned, they are being
+   requested to build an MP LSP whose root node is PE2.  They MUST NOT
+   interpret the opaque value at all.
+
+   When an mLDP Label Mapping message containing PE2-FEC arrives at PE2
+   over a VRF interface, PE2 notes that it is the identified root node
+   and that the opaque value is a VPN-Recursive Opaque Value.
+   Therefore, it MUST replace PE2-FEC with the contents of the
+   VPN-Recursive Opaque Value (i.e., with CE1-FEC) before doing any
+   further processing.  It uses the VRF to look up the path to R.  This
+   will result in CE1-FEC being sent on to CE2, and presumably further
+   from CE2 to R.
+
+   In this scenario, the RD in the VPN-Recursive Opaque Value also
+   ensures uniqueness of the FEC element within the inner carrier's
+   network.
+
+   This way of providing Carrier's Carrier service has limited
+   applicability, as it only works under the following conditions:
+
+   -  Both the inner carrier and the outer carrier are using non-
+      segmented mLDP P-tunnels.
+
+
+
+
+
+
+Wijnands, et al.             Standards Track                    [Page 9]
+
+RFC 6512         Using mLDP with Recursive Opaque Values   February 2012
+
+
+   -  The inner carrier is not aggregating the P-tunnels of the outer
+      carrier but is content to carry each such P-tunnel in a single
+      P-tunnel of its own.
+
+   The Carrier's Carrier scenario can be distinguished from the inter-AS
+   scenario by the fact that in the former, the mLDP messages are being
+   exchanged on VRF interfaces.
+
+4.  IANA Considerations
+
+   [mLDP] defines a registry for "The LDP MP Opaque Value Element Basic
+   Type".  Two new code points have been assigned in this registry:
+
+   -  Recursive Opaque Value: Type 7
+
+      An opaque value of this type is itself a TLV that encodes an mLDP
+      FEC type, as defined in [mLDP].
+
+   -  VPN-Recursive Opaque Value: Type 8
+
+      An opaque value of this type consists of an 8-octet Route
+      Distinguisher as defined in [VPN], followed by a TLV that encodes
+      an mLDP FEC type, as defined in [mLDP].
+
+5.  Security Considerations
+
+   The security considerations of [LDP] and [mLDP] apply.
+
+   Unauthorized modification of the FEC elements defined in this
+   document can disrupt the creation of the multipoint LSPs or can cause
+   the multipoint LSPs to pass through parts of the network where they
+   are not supposed to go.  This could potentially be used as part of an
+   attack to illegitimately insert or intercept multicast traffic.
+   However, since the FEC elements defined in this document are not
+   inherently more vulnerable to this form of attack than are the
+   previously defined FEC elements, this document does not add new
+   security vulnerabilities.
+
+   A description of general security issues for MPLS can be found in
+   [RFC5920].
+
+6.  Acknowledgments
+
+   The authors wish to thank Toerless Eckert for his contribution to
+   this work.
+
+
+
+
+
+
+Wijnands, et al.             Standards Track                   [Page 10]
+
+RFC 6512         Using mLDP with Recursive Opaque Values   February 2012
+
+
+7.  References
+
+7.1.  Normative References
+
+   [LDP]     Andersson, L., Ed., Minei, I., Ed., and B. Thomas, Ed.,
+             "LDP Specification", RFC 5036, October 2007.
+
+   [mLDP]    Wijnands, IJ., Ed., Minei, I., Ed., Kompella, K., and B.
+             Thomas, "Label Distribution Protocol Extensions for Point-
+             to-Multipoint and Multipoint-to-Multipoint Label Switched
+             Paths", RFC 6388, November 2011.
+
+   [MVPN]    Rosen, E., Ed., and R. Aggarwal, Ed., "Multicast in
+             MPLS/BGP IP VPNs", RFC 6513, February 2012.
+
+   [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+             Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [VPN]     Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private
+             Networks (VPNs)", RFC 4364, February 2006.
+
+7.2.  Informative References
+
+   [RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS
+             Networks", RFC 5920, July 2010.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Wijnands, et al.             Standards Track                   [Page 11]
+
+RFC 6512         Using mLDP with Recursive Opaque Values   February 2012
+
+
+Authors' Addresses
+
+   IJsbrand Wijnands
+   Cisco Systems, Inc.
+   De kleetlaan 6a Diegem 1831
+   Belgium
+   EMail: ice@cisco.com
+
+   Eric C. Rosen
+   Cisco Systems, Inc.
+   1414 Massachusetts Avenue
+   Boxborough, MA  01719
+   EMail: erosen@cisco.com
+
+   Maria Napierala
+   AT&T Labs
+   200 Laurel Avenue
+   Middletown, NJ  07748
+   EMail: mnapierala@att.com
+
+   Nicolai Leymann
+   Deutsche Telekom
+   Winterfeldtstrasse 21
+   Berlin  10781
+   Germany
+   EMail: n.leymann@telekom.de
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Wijnands, et al.             Standards Track                   [Page 12]
+