--- 1/draft-ietf-mpls-ldp-upstream-05.txt 2010-02-26 02:11:13.000000000 +0100 +++ 2/draft-ietf-mpls-ldp-upstream-06.txt 2010-02-26 02:11:13.000000000 +0100 @@ -1,22 +1,22 @@ Network Working Group R. Aggarwal Internet Draft Juniper Networks -Expiration Date: July 2010 +Expiration Date: August 2010 J. L. Le Roux France Telecom - January 29, 2010 + February 25, 2010 MPLS Upstream Label Assignment for LDP - draft-ietf-mpls-ldp-upstream-05.txt + draft-ietf-mpls-ldp-upstream-06.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. @@ -68,25 +68,26 @@ Table of Contents 1 Specification of requirements ......................... 3 2 Introduction .......................................... 3 3 LDP Upstream Label Assignment Capability .............. 3 4 Distributing Upstream-Assigned Labels in LDP .......... 4 4.1 Procedures ............................................ 5 5 LDP Tunnel Identifier Exchange ........................ 6 6 LDP Point-to-Multipoint LSPs on a LAN ................. 7 7 IANA Considerations ................................... 9 - 8 Acknowledgements ...................................... 9 - 9 References ............................................ 10 - 9.1 Normative References .................................. 10 - 9.2 Informative References ................................ 10 -10 Author's Address ...................................... 11 + 8 Security Considerations ............................... 9 + 9 Acknowledgements ...................................... 10 +10 References ............................................ 10 +10.1 Normative References .................................. 10 +10.2 Informative References ................................ 10 +11 Author's Address ...................................... 11 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 @@ -108,21 +109,21 @@ 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 peers, its support of upstream label assignment. This parameter follows the format and procedures for exchanging Capability - Parameters defined in [LDP-CAP]. + Parameters defined in [RFC5561]. Following is the format of the LDP Upstream Label Assignment Capability Parameter: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1|0| Upstream Lbl Ass Cap(IANA)| Length (= 1) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1| Reserved | @@ -158,49 +159,47 @@ 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - Label - This is a 20-bit label value as specified in [RFC3032] represented as a 20-bit number in a 4 octet field. 4.1. Procedures Procedures for Label Mapping, Label Request, Label Abort, Label - Withdraw and Label Release follow [RFC3036] other than the + 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 messages. A LDP LSR MUST NOT send the Upstream Assigned Label Request TLV to a neighboring LSR if the neighboring LSR had not previously advertised the Upstream Label Assignment Capability in its LDP Initialization messages. As described in [RFC5331] the distribution of upstream-assigned labels is similar to either ordered LSP control or independent LSP control of the downstream assigned labels. When the label distributed in a Label Mapping message is an upstream- assigned label, the Upstream Assigned Label TLV MUST be included in the Label Mapping message. When a LSR receives a Label Mapping message with an Upstream Assigned Label TLV and it does not recognize the TLV, it MUST generate a Notification message with a status code - of "Unknown TLV" [RFC3036]. If it does recognize the TLV but is + of "Unknown TLV" [RFC5036]. If it does recognize the TLV but is unable to process the upstream label, it MUST generate a Notification message with a status code of "No Label Resources". If the Label Mapping message was generated in response to a Label Request message, the Label Request message MUST contain an Upstream Assigned Label Request TLV. A LSR that generates an upstream assigned label request to a neighbor LSR, for a given FEC, MUST NOT send a downstream label mapping to the neighbor LSR for that FEC unless it withdraws the upstream-assigned label binding. Similarly if a LSR generates a downstream assigned label request to a neighbor LSR, for a given FEC, it MUST NOT send an upstream label mapping to that LSR for that FEC, @@ -358,86 +357,99 @@ LSRs on the LAN do not support upstream label assignment. Ingress replication and downstream label assignment will continue to be used for LSRs that do not support upstream label assignment. 7. IANA Considerations This document defines a new LDP Upstream Label Assignment Capability Parameter. IANA is requested to assign the value 0x0507 to this Parameter. - This document defines a new LDP Upstream-Assigned Label Request TLV, - IANA is requested to assign the type value of this TLV. - This document defines a new LDP Upstream-Assigned Label TLV, IANA is - requested to assign the type value of this TLV. + requested to assign the type value of 0x204 to this TLV. + + This document defines a new LDP Upstream-Assigned Label Request TLV, + IANA is requested to assign the type value of 0x205 to this TLV. This document defines four new Interface ID TLVs: - RSVP-TE P2MP LSP TLV - LDP P2MP LSP TLV - IP Multicast Tunnel TLV - MPLS Context Label TLV - IANA is requested to assign the type values of these TLVs. + These values are assigned from the Interface_ID Type space defined in + [RFC3471]. IANA is requested to assign the type value 6 to RSVP-TE + P2MP LSP TLV, type value 7 to LDP P2MP LSP TLV, type value 8 to IP + Multicast Tunnel TLV and type value 9 to MPLS Context Label TLV. -8. Acknowledgements +8. Security Considerations + + The security considerations discussed in 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]. -9. References - -9.1. Normative References +10. References - [RFC3031] "MPLS Architecture", E. Rosen, A. Viswanathan, R. Callon, - RFC 3031. +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. - [RFC3036] L. Andersson, et. al., "LDP Specification", January 2001. - -9.2. Informative References + [RFC5036] L. Andersson, et. al., "LDP Specification", RFC5036. - [MVPN] E. Rosen, R. Aggarwal [Editors], "Multicast in BGP/MPLS VPNs", - draft-ietf-l3vpn-2547bis-mcast-08.txt +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 Label Switched Paths", draft-etf-mpls-ldp- - p2mp-07.txt + Point-to-Multipoint and Multipoint-to-Multipoint Label Switched + Paths", draft-ietf-mpls-ldp-p2mp-08.txt - [LDP-CAP] B. Thomas, et. al., "LDP Capabilities", draft-thomas-mpls- - ldp-capabilities-04.txt + [RFC5561] B. Thomas, K. Raza, S. Aggarwal, R. Aggarwal, JL. Le Roux, + "LDP Capabilities", RFC5561 -10. Author's Address + [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 Rahul Aggarwal Juniper Networks 1194 North Mathilda Ave. Sunnyvale, CA 94089 Phone: +1-408-936-2720 Email: rahul@juniper.net Jean-Louis Le Roux France Telecom