--- 1/draft-ietf-mpls-ldp-upstream-07.txt 2010-07-26 17:14:55.000000000 +0200 +++ 2/draft-ietf-mpls-ldp-upstream-08.txt 2010-07-26 17:14:55.000000000 +0200 @@ -1,23 +1,23 @@ Network Working Group R. Aggarwal Internet Draft Juniper Networks Category: Standards Track -Expiration Date: September 2010 +Expiration Date: January 2011 J. L. Le Roux France Telecom - March 2, 2010 + July 26, 2010 MPLS Upstream Label Assignment for LDP - draft-ietf-mpls-ldp-upstream-07.txt + draft-ietf-mpls-ldp-upstream-08.txt Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and 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. @@ -56,65 +56,66 @@ the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. Abstract This document describes procedures for distributing upstream-assigned labels for Label Distribution Protocol (LDP). It also describes how - these procedures can be used for avoiding branch LSR traffic - replication on a LAN for LDP point-to-multipoint (P2MP)LSPs. + these procedures can be used for avoiding branch Label Switching + Router (LSR) traffic replication on a LAN for LDP point-to-multipoint + (P2MP) Label Switched Paths (LSPs). Table of Contents 1 Specification of requirements ......................... 3 2 Introduction .......................................... 3 3 LDP Upstream Label Assignment Capability .............. 4 4 Distributing Upstream-Assigned Labels in LDP .......... 5 4.1 Procedures ............................................ 5 5 LDP Tunnel Identifier Exchange ........................ 6 - 6 LDP Point-to-Multipoint LSPs on a LAN ................. 8 - 7 IANA Considerations ................................... 9 - 7.1 LDP TLVs .............................................. 9 - 7.2 Interface Type Identifiers ............................ 10 - 8 Security Considerations ............................... 10 - 9 Acknowledgements ...................................... 11 -10 References ............................................ 11 -10.1 Normative References .................................. 11 -10.2 Informative References ................................ 11 -11 Author's Address ...................................... 12 + 6 LDP Point-to-Multipoint LSPs on a LAN ................. 10 + 7 IANA Considerations ................................... 12 + 7.1 LDP TLVs .............................................. 12 + 7.2 Interface Type Identifiers ............................ 12 + 8 Security Considerations ............................... 12 + 9 Acknowledgements ...................................... 13 +10 References ............................................ 13 +10.1 Normative References .................................. 13 +10.2 Informative References ................................ 13 +11 Author's Address ...................................... 14 1. Specification of requirements 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. Introduction This document describes procedures for distributing upstream-assigned - labels [RFC5331] for Label Distribution Protocol (LDP). These - procedures follow the architecture for MPLS Upstream Label Assignment - described in [RFC5331]. + labels [RFC5331] for Label Distribution Protocol (LDP) [RFC5036]. + These procedures follow the architecture for MPLS Upstream Label + Assignment described in [RFC5331]. - This document describes extensions to LDP that a LSR can use to - advertise to its neighboring LSRs whether the LSR supports upstream - label assignment. + This document describes extensions to LDP that a Label Switching + Router (LSR) can use to advertise to its neighboring LSRs whether the + LSR supports upstream label assignment. This document also describes extensions to LDP to distribute upstream-assigned labels. The usage of MPLS upstream label assignment using LDP for avoiding - branch LSR traffic replication on a LAN for LDP P2MP LSPs [MLDP] is - also described. + branch LSR traffic replication on a LAN for LDP point-to-multipoint + (P2MP) Label Switched Paths (LSPs) [MLDP] is also described. 3. LDP Upstream Label Assignment Capability According to [RFC5331], upstream-assigned label bindings MUST NOT be used unless it is known that a downstream LSR supports them. This implies that there MUST be a mechanism to enable a LSR to advertise to its LDP neighbor LSR(s) its support of upstream-assigned labels. A new Capability Parameter, the LDP Upstream Label Assignment Capability, is introduced to allow an LDP peer to exchange with its @@ -131,28 +132,28 @@ |1|0| Upstream Lbl Ass Cap(IANA)| Length (= 1) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1| Reserved | +-+-+-+-+-+-+-+-+ If a LSR includes the Upstream Label Assignment Capability in LDP Initialization Messages it implies that the LSR is capable of both distributing upstream-assigned label bindings and receiving upstream- assigned label bindings. The reserved bits MUST be set to zero on transmission and ignored on receipt. The Upstream Label Assignment - Capability Parameter can be exchanged only in LDP initialization - messages. + Capability Parameter MUST be carried only LDP initialization messages + and MUST be ignored if received in LDP Capability messages. 4. Distributing Upstream-Assigned Labels in LDP An optional LDP TLV, Upstream-Assigned Label Request TLV, is - introduced. This TLV MUST be carried in a Label Request message if - an upstream-assigned label is being requested. + introduced. To request an upstream-assigned label a LDP peer MUST + include this TLV in a Label Request message. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0|0| Upstream Ass Lbl Req (TBD)| Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ An optional LDP TLV, Upstream-Assigned Label TLV is introduced to @@ -163,22 +164,23 @@ 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0|0| Upstream Ass Label (TBD) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Label | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - This is a 20-bit label value as specified in [RFC3032] represented as - a 20-bit number in a 4 octet field. + The Label field is a 20-bit label value as specified in [RFC3032] + represented as a 20-bit number in a 4 octet field as specified in + section 3.4.2.1 of RFC5036 [RFC5036]. 4.1. Procedures Procedures for Label Mapping, Label Request, Label Abort, Label Withdraw and Label Release follow [RFC5036] other than the modifications pointed out in this section. A LDP LSR MUST NOT distribute the Upstream Assigned Label TLV to a neighboring LSR if the neighboring LSR had not previously advertised the Upstream Label Assignment Capability in its LDP Initialization @@ -226,57 +228,153 @@ When LDP is used for upstream label assignment, the Interface ID TLV [RFC3472] is used for signaling the Tunnel Identifier. If Ru uses an IP or MPLS tunnel to transmit MPLS packets with upstream assigned labels to Rd, Ru MUST include the Interface ID TLV in the Label Mapping messages along with the Upstream Assigned Label TLV. The IPv4/v6 Next/Previous Hop Address and the Logical Interface ID fields in the Interface ID TLV SHOULD be set to 0 by the sender and ignored by the receiver. - The Interface ID TLV carries sub-TLVs. Four new Interface ID sub-TLVs - are introduced to support RSVP-TE P2MP LSPs, LDP P2MP LSPs, IP - Multicast Tunnels and context labels. The TLV value in the sub-TLV - acts as the tunnel identifier. Following are the sub-TLVs that are - introduced: + Hence the IPv4 Interface ID TLV has the following format: - 1. RSVP-TE P2MP LSP TLV. Type = TBD. Value of the TLV is - as carried in the - RSVP-TE P2MP LSP SESSION Object [RFC4875]. The TLV value identifies - the RSVP-TE P2MP LSP. It allows Ru to tunnel an "inner" LDP P2MP LSP, - the label for which is upstream assigned, over an "outer" RSVP-TE - P2MP LSP that has leaves . The RSVP-TE P2MP LSP IF_ID TLV - allows Ru to signal to the binding of the inner LDP P2MP - LSP to the outer RSVP-TE P2MP LSP. The control plane signaling - between Ru and for the inner P2MP LSP uses targeted LDP - signaling messages + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |0|0| Type (0x082d) | Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | IPv4 Next/Previous Hop Address (0) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Logical Interface ID (0) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Sub-TLVs | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - 2. LDP P2MP LSP TLV. Type = TBD. Value of the TLV is the LDP P2MP FEC - as defined in [MLDP]. The TLV value identifies the LDP P2MP LSP. It - allows Ru to tunnel an "inner" LDP P2MP LSP, the label for which is - upstream assigned, over an "outer" LDP P2MP LSP that has leaves - . The LDP P2MP LSP IF_ID TLV allows Ru to signal to - the binding of the inner LDP P2MP LSP to the outer LDP- - P2MP LSP. The control plane signaling between Ru and for - the inner P2MP LSP uses targeted LDP signaling messages + The IPv6 Interface ID TLV has the following format: - 3. IP Multicast Tunnel TLV. Type = TBD. In this case the TLV value is - a tuple. Source Address is - the IP address of the root of the tunnel i.e. Ru, and Multicast Group - Address is the Multicast Group Address used by the tunnel. + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |0|0| Type (0x082e) | Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | IPv6 Next/Previous Hop Address (0) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Logical Interface ID (0) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Sub-TLVs | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - 4. MPLS Context Label TLV. Type = TBD. In this case the TLV value is - a tuple. The Source Address - belongs to Ru and the MPLS Context Label is an upstream assigned - label, assigned by Ru. This allows Ru to tunnel an "inner" LDP P2MP - LSP, the label of which is upstream assigned, over an "outer" one-hop - MPLS LSP, where the outer one-hop LSP has the following property: + As shown in the above figures the Interface ID TLV carries sub-TLVs. + Four new Interface ID sub-TLVs are introduced to support RSVP-TE P2MP + LSPs, LDP P2MP LSPs, IP Multicast Tunnels and context labels. The TLV + value in the sub-TLV acts as the tunnel identifier. + + Following are the sub-TLVs that are introduced: + + 1. RSVP-TE P2MP LSP TLV. Type = 28 (To be assigned by IANA). Value of + the TLV is as carried in the RSVP-TE P2MP LSP SESSION Object + [RFC4875]. + + Below is the RSVP-TE P2MP LSP TLV format when carried in the IPv4 + Interface ID 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 = 28 | 16 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | P2MP ID | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | MUST be zero | Tunnel ID | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Extended Tunnel ID | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Below is the RSVP-TE P2MP LSP TLV format when carried in the IPv6 + Interface ID 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 = 28 | 28 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | P2MP ID | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | MUST be zero | Tunnel ID | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Extended Tunnel ID | + | | + | ....... | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + This TLV identifies the RSVP-TE P2MP LSP. It allows Ru to tunnel an + "inner" LDP P2MP LSP, the label for which is upstream assigned, over + an "outer" RSVP-TE P2MP LSP that has leaves . The RSVP-TE + P2MP LSP IF_ID TLV allows Ru to signal to the binding of + the inner LDP P2MP LSP to the outer RSVP-TE P2MP LSP. The control + plane signaling between Ru and for the inner P2MP LSP + uses targeted LDP signaling messages + + 2. LDP P2MP LSP TLV. Type = 29 (To be assigned by IANA). Value of the + TLV is the LDP P2MP FEC as defined in [MLDP] and has to be set as per + the procedures in [MLDP]. Here is the format of the LDP P2MP FEC as + defined in [MLDP]: + + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |P2MP Type | Address Family | Address Length| + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + ~ Root Node Address ~ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Opaque Length | Opaque Value ... | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + ~ ~ + | | + | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + The Address Family MUST be set to IPv4, the Address Length MUST be + set to 4 and the Root Node Address MUST be set to an IPv4 address + when the LDP P2MP LSP TLV is carried in the IPv4 Interface ID TLV. + The Address Family MUST be set to IPv6, the Address Length MUST be + set to 16 and the Root Node Address MUST be set to an IPv6 address + when the LDP P2MP LSP TLV is carried in the IPv6 Interface ID TLV. + + The TLV value identifies the LDP P2MP LSP. It allows Ru to tunnel an + "inner" LDP P2MP LSP, the label for which is upstream assigned, over + an "outer" LDP P2MP LSP that has leaves . The LDP P2MP LSP + IF_ID TLV allows Ru to signal to the binding of the + inner LDP P2MP LSP to the outer LDP- P2MP LSP. The control plane + signaling between Ru and for the inner P2MP LSP uses + targeted LDP signaling messages + + 3. IP Multicast Tunnel TLV. Type = 30 (To be assigned by IANA) In + this case the TLV value is a tuple. Source Address is the IP address of the root of the + tunnel i.e. Ru, and Multicast Group Address is the Multicast Group + Address used by the tunnel. The addresses MUST be IPv4 addresses when + the IP Multicast Tunnel TLV is included in the IPv4 Interface ID TLV. + The addresses MUST be IPv6 addresses when the IP Multicast Tunnel TLV + is included in the IPv6 Interface ID TLV. + + 4. MPLS Context Label TLV. Type = 31 (To be assigned by IANA). In + this case the TLV value is a + tuple. The Source Address belongs to Ru and the MPLS Context Label is + an upstream assigned label, assigned by Ru. The Source Address MUST + be set to an IPv4 address when the MPLS Context Label TLV is carried + in the IPv4 Interface ID TLV. The Source Address MUST be set to an + IPv6 address when the MPLS Context Label TLV is carried in the IPv6 + Interface ID TLV. This allows Ru to tunnel an "inner" LDP P2MP LSP, + the label of which is upstream assigned, over an "outer" one-hop MPLS + LSP, where the outer one-hop LSP has the following property: + The label pushed by Ru for the outer MPLS LSP is an upstream assigned context label, assigned by Ru. When perform a MPLS label lookup on this label a combination of this label and the incoming interface MUST be sufficient for to uniquely determine Ru's context specific label space to lookup the next label on the stack in. MUST receive the data sent by Ru with the context specific label assigned by Ru being the top label on the label stack. @@ -396,68 +494,65 @@ - RSVP-TE P2MP LSP TLV (requested value 28) - LDP P2MP LSP TLV (requested value 29) - IP Multicast Tunnel TLV (requested value 30) - MPLS Context Label TLV (requested value 31) 8. Security Considerations - The security considerations discussed in RFC 5331 and RFC 5332 apply - to this document. + The security considerations discussed in RFC 5036, RFC 5331 and RFC + 5332 apply to this document. More detailed discussion of security issues that are relevant in the context of MPLS and GMPLS, including security threats, related defensive techniques, and the mechanisms for detection and reporting, are discussed in "Security Framework for MPLS and GMPLS Networks + [MPLS-SEC]. 9. Acknowledgements Thanks to Yakov Rekhter for his contribution. Thanks to Ina Minei and Thomas Morin for their comments. The hashing algorithm used on LAN interfaces is taken from [MLDP]. Thanks to Loa Andersson and Adrian - Farrel for their comments on the IANA section. + Farrel for their comments and review. 10. References 10.1. Normative References [RFC5331] R. Aggarwal, Y. Rekhter, E. Rosen, "MPLS Upstream Label Assignment and Context Specific Label Space", RFC5331 [RFC5332] T. Eckert, E. Rosen, R. Aggarwal, Y. Rekhter, RFC5332 [RFC2119] "Key words for use in RFCs to Indicate Requirement Levels.", Bradner, March 1997 [RFC3472] Ashwood-Smith, P. and L. Berger, Editors, " Generalized Multi-Protocol Label Switching (GMPLS) Signaling - Constraint-based Routed Label Distribution Protocol (CR-LDP) Extensions", RFC 3472, January 2003. - [RFC3471] Berger, L. Editor, "Generalized Multi-Protocol Label - Switching (GMPLS) Signaling Functional Description", RFC 3471 January - 2003. - [RFC5036] L. Andersson, et. al., "LDP Specification", RFC5036. -10.2. Informative References - [RFC4875] R. Aggarwal, D. Papadimitriou, S. Yasukawa [Editors], "Extensions to RSVP-TE for Point to Multipoint TE LSPs", RFC 4875 [MLDP] I. Minei et. al, "Label Distribution Protocol Extensions for Point-to-Multipoint and Multipoint-to-Multipoint Label Switched Paths", draft-ietf-mpls-ldp-p2mp-08.txt +10.2. Informative References + [RFC5561] B. Thomas, K. Raza, S. Aggarwal, R. Aggarwal, JL. Le Roux, "LDP Capabilities", RFC5561 [MPLS-SEC] L. fang, ed, "Security Framework for MPLS and GMPLS Networks", draft-ietf-mpls-mpls-and-gmpls-security-framework-07.txt [RFC3032] E. Rosen et. al, "MPLS Label Stack Encoding", RFC 3032 11. Author's Address