doc: Add RFC documents

1 files changed, 675 insertions, 0 deletions

diff --git a/doc/rfc/rfc6826.txt b/doc/rfc/rfc6826.txt
new file mode 100644
index 0000000..b37ed41
--- /dev/null
+++ b/doc/rfc/rfc6826.txt
@@ -0,0 +1,675 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF)                 IJ. Wijnands, Ed.
+Request for Comments: 6826                                     T. Eckert
+Category: Standards Track                            Cisco Systems, Inc.
+ISSN: 2070-1721                                               N. Leymann
+                                                        Deutsche Telekom
+                                                            M. Napierala
+                                                               AT&T Labs
+                                                            January 2013
+
+
+                  Multipoint LDP In-Band Signaling for
+ Point-to-Multipoint and Multipoint-to-Multipoint Label Switched Paths
+
+Abstract
+
+   Consider an IP multicast tree, constructed by Protocol Independent
+   Multicast (PIM), that needs to pass through an MPLS domain in which
+   Multipoint LDP (mLDP) point-to-multipoint and/or multipoint-to-
+   multipoint Labels Switched Paths (LSPs) can be created.  The part of
+   the IP multicast tree that traverses the MPLS domain can be
+   instantiated as a multipoint LSP.  When a PIM Join message is
+   received at the border of the MPLS domain, information from that
+   message is encoded into mLDP messages.  When the mLDP messages reach
+   the border of the next IP domain, the encoded information is used to
+   generate PIM messages that can be sent through the IP domain.  The
+   result is an IP multicast tree consisting of a set of IP multicast
+   sub-trees that are spliced together with a multipoint LSP.  This
+   document describes procedures regarding how IP multicast trees are
+   spliced together with multipoint LSPs.
+
+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/rfc6826.
+
+
+
+
+
+
+
+
+Wijnands, et al.             Standards Track                    [Page 1]
+
+RFC 6826               In-Band Signaling with mLDP          January 2013
+
+
+Copyright Notice
+
+   Copyright (c) 2013 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
+   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
+     1.1.  Conventions Used in This Document  . . . . . . . . . . . .  3
+     1.2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . .  3
+   2.  In-Band Signaling for MP LSPs  . . . . . . . . . . . . . . . .  4
+     2.1.  Transiting Unidirectional IP Multicast Shared Trees  . . .  6
+     2.2.  Transiting IP Multicast Source Trees . . . . . . . . . . .  6
+     2.3.  Transiting IP Multicast Bidirectional Trees  . . . . . . .  7
+   3.  LSP Opaque Encodings . . . . . . . . . . . . . . . . . . . . .  8
+     3.1.  Transit IPv4 Source TLV  . . . . . . . . . . . . . . . . .  8
+     3.2.  Transit IPv6 Source TLV  . . . . . . . . . . . . . . . . .  8
+     3.3.  Transit IPv4 Bidir TLV . . . . . . . . . . . . . . . . . .  9
+     3.4.  Transit IPv6 Bidir TLV . . . . . . . . . . . . . . . . . .  9
+   4.  Security Considerations  . . . . . . . . . . . . . . . . . . . 10
+   5.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 10
+   6.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
+     6.1.  Normative References . . . . . . . . . . . . . . . . . . . 10
+     6.2.  Informative References . . . . . . . . . . . . . . . . . . 10
+   7.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 11
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Wijnands, et al.             Standards Track                    [Page 2]
+
+RFC 6826               In-Band Signaling with mLDP          January 2013
+
+
+1.  Introduction
+
+   The mLDP (Multipoint LDP) [RFC6388] specification describes
+   mechanisms for creating point-to-multipoint (P2MP) and multipoint-to-
+   multipoint (MP2MP) LSPs (Label Switched Paths).  These LSPs are
+   typically used for transporting end-user multicast packets.  However,
+   the mLDP specification does not provide any rules for associating
+   particular end-user multicast packets with any particular LSP.  Other
+   documents, like [RFC6513], describe applications in which out-of-band
+   signaling protocols, such as PIM and BGP, are used to establish the
+   mapping between an LSP and the multicast packets that need to be
+   forwarded over the LSP.
+
+   This document describes an application in which the information
+   needed to establish the mapping between an LSP and the set of
+   multicast packets to be forwarded over it is carried in the "opaque
+   value" field of an mLDP FEC (Forwarding Equivalence Class) element.
+   When an IP multicast tree (either a source-specific tree or a
+   bidirectional tree) enters the MPLS network, the (S,G) or (*,G)
+   information from the IP multicast control-plane state is carried in
+   the opaque value field of the mLDP FEC message.  As the tree leaves
+   the MPLS network, this information is extracted from the FEC Element
+   and used to build the IP multicast control plane.  PIM messages can
+   be sent outside the MPLS domain.  Note that although the PIM control
+   messages are sent periodically, the mLDP messages are not.
+
+   Each IP multicast tree is mapped one-to-one to a P2MP or MP2MP LSP in
+   the MPLS network.  A network operator should expect to see as many
+   LSPs in the MPLS network as there are IP multicast trees.  A network
+   operator should be aware how IP multicast state is created in the
+   network to ensure that it does not exceed the scalability numbers of
+   the protocol, either PIM or mLDP.
+
+1.1.  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 RFC 2119 [RFC2119].
+
+1.2.  Terminology
+
+   ASM:  PIM Any Source Multicast
+
+   Egress LSR:  One of potentially many destinations of an LSP; also
+      referred to as leaf node in the case of P2MP and MP2MP LSPs.
+
+
+
+
+
+
+Wijnands, et al.             Standards Track                    [Page 3]
+
+RFC 6826               In-Band Signaling with mLDP          January 2013
+
+
+   In-band signaling:  Using the opaque value of an mLDP FEC Element to
+      carry the (S,G) or (*,G) identifying a particular IP multicast
+      tree.
+
+   Ingress LSR:  Source of the P2MP LSP; also referred to as a root
+      node.
+
+   IP multicast tree:  An IP multicast distribution tree identified by
+      an IP multicast Group address and, optionally, by a Source IP
+      address, also referred to as (S,G) and (*,G).
+
+   LSR: Label Switching Router
+
+   LSP: Labels Switched Path
+
+   mLDP:  Multipoint LDP
+
+   MP2MP LSP:  An LSP that connects a set of leaf nodes that may each
+      independently act as ingress or egress.
+
+   MP LSP:  A multipoint LSP, either a P2MP or an MP2MP LSP.
+
+   P2MP LSP:  An LSP that has one Ingress Label Switching Router (LSR)
+      and one or more Egress LSRs.
+
+   RP:  PIM Rendezvous Point
+
+   SSM:  PIM Source-Specific Multicast
+
+   Transit LSP:  A P2MP or MP2MP LSP whose FEC Element contains the
+      (S,G) or (*,G) identifying a particular IP multicast distribution
+      tree.
+
+   Transit LSR:  An LSR that has one or more directly connected
+      downstream LSRs.
+
+2.  In-Band Signaling for MP LSPs
+
+   Consider the following topology:
+
+                  |--- IPM ---|--- MPLS --|--- IPM ---|
+
+               S/RP -- (A) - (U) - (C) - (D) -- (B) -- R
+
+                                Figure 1
+
+
+
+
+
+
+Wijnands, et al.             Standards Track                    [Page 4]
+
+RFC 6826               In-Band Signaling with mLDP          January 2013
+
+
+   Nodes A and B are IP-multicast-capable routers and connect to a
+   Source/RP and a Receiver, respectively.  Nodes U, C, and D are MPLS
+   Label Switched Routers (LSRs).
+
+   LSR D is attached to a network that is capable of MPLS multicast and
+   IP multicast (see figure 1), and D is required to create a IP
+   multicast tree due to a certain IP multicast event, like a PIM Join,
+   MSDP Source Announcement (SA) [RFC3618], BGP Source Active auto-
+   discovery route [SM-MLDP], or Rendezvous Point (RP) discovery.
+   Suppose that D can determine that the IP multicast tree needs to
+   travel through the MPLS network until it reaches LSR U.  For
+   instance, when D looks up the route to the Source or RP [RFC4601] of
+   the IP multicast tree, it may discover that the route is a BGP route
+   with U as the BGP next hop.  Then D may choose to set up a P2MP or an
+   MP2MP LSP, with U as root, and to make that LSP become part of the IP
+   multicast distribution tree.  Note that other methods are possible to
+   determine that an IP multicast tree is to be transported across an
+   MPLS network using P2MP or MP2MP LSPs.  However, these methods are
+   outside the scope of this document.
+
+   In order to establish a multicast tree via a P2MP or MP2MP LSP using
+   "in-band signaling", LSR D encodes a P2MP or MP2MP FEC Element, with
+   the IP address of LSR U as the "Root Node Address" and with the
+   source and the group encoded into the "opaque value" ([RFC6388],
+   Sections 2.2 and 3.2).  Several different opaque value types are
+   defined in this document.  LSR D MUST NOT use a particular opaque
+   value type unless it knows (through provisioning or through some
+   other means outside the scope of this document) that LSR U supports
+   the root node procedures for that opaque value type.
+
+   The particular type of FEC Element and opaque value used depends on
+   the IP address family being used, and on whether the multicast tree
+   being established is a source-specific or a bidirectional multicast
+   tree.
+
+   When an LSR receives a label mapping or withdraw whose FEC Element
+   contains one of the opaque value types defined in this document, and
+   that LSR is not the one identified by the "Root Node Address" field
+   of that FEC Element, the LSR follows the procedures provided in RFC
+   6388.
+
+   When an LSR receives a label mapping or withdraw whose FEC Element
+   contains one of the opaque value types defined in this document, and
+   that LSR is the one identified by the Root Node Address field of that
+   FEC Element, then the following procedure is executed.  The multicast
+   source and group are extracted and passed to the multicast code.  If
+   a label mapping is being processed, the multicast code will add the
+   downstream LDP neighbor to the olist of the corresponding (S,G) or
+
+
+
+Wijnands, et al.             Standards Track                    [Page 5]
+
+RFC 6826               In-Band Signaling with mLDP          January 2013
+
+
+   (*,G) state, creating such state if it does not already exist.  If a
+   label withdraw is being processed, the multicast code will remove the
+   downstream LDP neighbor from the olist of the corresponding (S,G) or
+   (*,G) state.  From this point on, normal PIM processing will occur.
+
+   Note that if the LSR identified by the Root Node Address field does
+   not recognize the opaque value type, the MP LSP will be established,
+   but the root node will not send any multicast data packets on it.
+
+   Source or RP addresses that are reachable in a VPN context are
+   outside the scope of this document.
+
+   Multicast groups that operate in PIM Dense-Mode are outside the scope
+   of this document.
+
+2.1.  Transiting Unidirectional IP Multicast Shared Trees
+
+   Nothing prevents PIM shared trees, used by PIM-SM in the ASM service
+   model, from being transported across an MPLS core.  However, it is
+   not possible to prune individual sources from the shared tree without
+   the use of an additional out-of-band signaling protocol, like PIM or
+   BGP [SM-MLDP].  For this reason, transiting shared trees across a
+   transit LSP is outside the scope of this document.
+
+2.2.  Transiting IP Multicast Source Trees
+
+   IP multicast source trees can be created via PIM operating in either
+   SSM mode [RFC4607] or ASM mode [RFC4601].  When PIM-SM is used in ASM
+   mode, the usual means of discovering active sources is to join a
+   sparse-mode shared tree.  However, this document does not provide any
+   method of establishing a sparse-mode shared tree across an MPLS
+   network.  To apply the technique of this document to PIM-SM in ASM
+   mode, there must be some other means of discovering the active
+   sources.  One possible means is the use of MSDP [RFC3618].  Another
+   possible means is to use BGP Source Active auto-discovery routes, as
+   documented in [SM-MLDP].  However, the method of discovering the
+   active sources is outside the scope of this document; as a result,
+   this document does not specify everything that is needed to support
+   the ASM service model using in-band signaling.
+
+   The source and group addresses are encoded into the a transit TLV as
+   specified in Sections 3.1 and 3.2.
+
+
+
+
+
+
+
+
+
+Wijnands, et al.             Standards Track                    [Page 6]
+
+RFC 6826               In-Band Signaling with mLDP          January 2013
+
+
+2.3.  Transiting IP Multicast Bidirectional Trees
+
+   If a bidirectional IP multicast tree [RFC5015] has to be transported
+   over an MPLS network using in-band signaling, as described in this
+   document, it MUST be transported using an MP2MP LSPs.  A
+   bidirectional tree does not have a specific source address; the group
+   address, subnet mask, and RP are relevant for multicast forwarding.
+   This document does not provide procedures to discover RP-to-group
+   mappings dynamically across an MPLS network and assumes the RP is
+   statically defined.  Support of dynamic RP mappings in combination
+   with in-band signaling is outside the scope of this document.
+
+   The RP for the group is used to select the ingress LSR and the root
+   of the LSP.  The group address is encoded according to the rules of
+   Sections 3.3 or 3.4, depending on the IP version.  The subnet mask
+   associated with the bidirectional group is encoded in the Transit
+   TLV.  There are two types of bidirectional states in IP multicast,
+   the group specific state and the RP state.  The first type is
+   typically created when a PIM Join has been received and has a subnet
+   mask of 32 for IPv4 and 128 for IPv6.  The RP state is typically
+   created via the static RP mapping and has a variable subnet mask.
+   The RP state is used to build a tree to the RP and is used for
+   sender-only branches.  Each state (group specific and RP state) will
+   result in a separate MP2MP LSP.  The merging of the two MP2MP LSPs
+   will be done by PIM on the root LSR.  No special procedures are
+   necessary for PIM to merge the two LSPs.  Each LSP is effectively
+   treated as a PIM-enabled interface.  Please see [RFC5015] for more
+   details.
+
+   For transporting the packets of a sender-only branch, we create a
+   MP2MP LSP.  Other sender-only branches will receive these packets and
+   will not forward them because there are no receivers.  These packets
+   will be dropped.  If that effect is undesirable, some other means of
+   transport has to be established to forward packets to the root of the
+   tree, for example, a multipoint-to-point LSP for example.  A
+   technique to unicast packets to the root of a P2MP or MP2MP LSP is
+   documented in Section 3.2.2.1 of [MVPN-MSPMSI].
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Wijnands, et al.             Standards Track                    [Page 7]
+
+RFC 6826               In-Band Signaling with mLDP          January 2013
+
+
+3.  LSP Opaque Encodings
+
+   This section documents the different transit opaque encodings.
+
+3.1.  Transit IPv4 Source TLV
+
+   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          | Length                        | Source        |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                                               | Group         |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                                               |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   Type:  3
+
+   Length:  8 (octet size of Source and Group fields)
+
+   Source:  IPv4 multicast source address, 4 octets
+
+   Group:  IPv4 multicast group address, 4 octets
+
+3.2.  Transit IPv6 Source TLV
+
+   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          | Length                        | Source        ~
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   ~                                               | Group         ~
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   ~                                               |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   Type:  4
+
+   Length:  32 (octet size of Source and Group fields)
+
+   Source:  IPv6 multicast source address, 16 octets
+
+   Group:  IPv6 multicast group address, 16 octets.
+
+
+
+
+
+
+
+
+Wijnands, et al.             Standards Track                    [Page 8]
+
+RFC 6826               In-Band Signaling with mLDP          January 2013
+
+
+3.3.  Transit IPv4 Bidir TLV
+
+   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          | Length                        | Mask Len      |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                              RP                               |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                            Group                              |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   Type:  5
+
+   Length:  9 (octet size of Mask Len, RP, and Group fields)
+
+   Mask Len:  The number of contiguous one bits that are left-justified
+      and used as a mask, 1 octet.  Maximum value allowed is 32.
+
+   RP:  Rendezvous Point (RP) IPv4 address used for the encoded Group, 4
+      octets.
+
+   Group:  IPv4 multicast group address, 4 octets.
+
+3.4.  Transit IPv6 Bidir TLV
+
+   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          | Length                        | Mask Len      |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+    |                             RP                               ~
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   ~                                                               |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                            Group                              ~
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   ~                                                               |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   Type:  6
+
+   Length:  33 (octet size of Mask Len, RP and Group fields)
+
+   Mask Len:  The number of contiguous one bits that are left-justified
+      and used as a mask, 1 octet.  Maximum value allowed is 128.
+
+
+
+
+
+Wijnands, et al.             Standards Track                    [Page 9]
+
+RFC 6826               In-Band Signaling with mLDP          January 2013
+
+
+   RP:  Rendezvous Point (RP) IPv6 address used for encoded group, 16
+      octets.
+
+   Group:  IPv6 multicast group address, 16 octets.
+
+4.  Security Considerations
+
+   The same security considerations apply as for the base LDP
+   specification, as described in [RFC5036].
+
+5.  IANA Considerations
+
+   IANA has allocated the following values from the "LDP MP Opaque Value
+   Element basic type" registry: are:
+
+      Transit IPv4 Source TLV type - 3
+
+      Transit IPv6 Source TLV type - 4
+
+      Transit IPv4 Bidir TLV type - 5
+
+      Transit IPv6 Bidir TLV type - 6
+
+6.  References
+
+6.1.  Normative References
+
+   [RFC5036]  Andersson, L., Ed., Minei, I., Ed., and B. Thomas, Ed.,
+              "LDP Specification", RFC 5036, October 2007.
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC6388]  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.
+
+6.2.  Informative References
+
+   [RFC4601]  Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas,
+              "Protocol Independent Multicast - Sparse Mode (PIM-SM):
+              Protocol Specification (Revised)", RFC 4601, August 2006.
+
+   [RFC4607]  Holbrook, H. and B. Cain, "Source-Specific Multicast for
+              IP", RFC 4607, August 2006.
+
+
+
+
+
+Wijnands, et al.             Standards Track                   [Page 10]
+
+RFC 6826               In-Band Signaling with mLDP          January 2013
+
+
+   [RFC5015]  Handley, M., Kouvelas, I., Speakman, T., and L. Vicisano,
+              "Bidirectional Protocol Independent Multicast (BIDIR-
+              PIM)", RFC 5015, October 2007.
+
+   [RFC3618]  Fenner, B., Ed., and D. Meyer, Ed., "Multicast Source
+              Discovery Protocol (MSDP)", RFC 3618, October 2003.
+
+   [RFC6513]  Rosen, E., Ed., and R. Aggarwal, Ed., "Multicast in
+              MPLS/BGP IP VPNs", RFC 6513, February 2012.
+
+   [SM-MLDP]  Rekhter, Y., Aggarwal, R., and N. Leymann, "Carrying PIM-
+              SM in ASM mode Trees over P2MP mLDP LSPs", Work in
+              Progress, August 2011.
+
+   [MVPN-MSPMSI]
+              Cai, Y., Rosen, E., Ed., Napierala, M., and A. Boers,
+              MVPN: Optimized use of PIM via MS-PMSIs", February 2012.
+
+7.  Acknowledgments
+
+   Thanks to Eric Rosen for his valuable comments on this document.
+   Also thanks to Yakov Rekhter, Adrian Farrel, Uwe Joorde, Loa
+   Andersson and Arkadiy Gulko for providing comments on this document.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Wijnands, et al.             Standards Track                   [Page 11]
+
+RFC 6826               In-Band Signaling with mLDP          January 2013
+
+
+Authors' Addresses
+
+   IJsbrand Wijnands (editor)
+   Cisco Systems, Inc.
+   De kleetlaan 6a
+   Diegem  1831
+   Belgium
+
+   EMail: ice@cisco.com
+
+
+   Toerless Eckert
+   Cisco Systems, Inc.
+   170 Tasman Drive
+   San Jose  CA, 95134
+   USA
+
+   EMail: eckert@cisco.com
+
+
+   Nicolai Leymann
+   Deutsche Telekom
+   Winterfeldtstrasse 21
+   Berlin  10781
+   Germany
+
+   EMail: n.leymann@telekom.de
+
+
+   Maria Napierala
+   AT&T Labs
+   200 Laurel Avenue
+   Middletown  NJ 07748
+   USA
+
+   EMail: mnapierala@att.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Wijnands, et al.             Standards Track                   [Page 12]
+