--- 1/draft-ietf-mpls-upstream-label-05.txt 2008-06-06 00:12:36.000000000 +0200 +++ 2/draft-ietf-mpls-upstream-label-06.txt 2008-06-06 00:12:36.000000000 +0200 @@ -1,25 +1,25 @@ Network Working Group R. Aggarwal Internet Draft Juniper Networks Category: Standards Track -Expiration Date: October 2008 Y. Rekhter +Expiration Date: December 2008 Y. Rekhter Juniper Networks E. Rosen Cisco Systems, Inc. - April 30, 2008 + June 05, 2008 MPLS Upstream Label Assignment and Context-Specific Label Space - draft-ietf-mpls-upstream-label-05.txt + draft-ietf-mpls-upstream-label-06.txt 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 @@ -47,72 +47,69 @@ Table of Contents 1 Specification of requirements ......................... 2 2 Introduction .......................................... 2 3 Context-Specific Label Space .......................... 3 4 Upstream Label Assignment ............................. 4 4.1 Upstream-Assigned and Downstream-Assigned Labels ...... 5 5 Assigning Upstream-Assigned Labels .................... 5 6 Distributing Upstream-Assigned Labels ................. 6 - 7 Upstream Neighbor Label Space ......................... 6 + 7 Upstream Neighbor Label Space ......................... 7 8 Context Label on LANs ................................. 9 9 Usage of Upstream-Assigned Labels ..................... 10 -10 IANA Considerations ................................... 10 +10 IANA Considerations ................................... 11 11 Security Considerations ............................... 11 12 Acknowledgements ...................................... 11 -13 References ............................................ 11 -13.1 Normative References .................................. 11 -13.2 Informative References ................................ 11 +13 References ............................................ 12 +13.1 Normative References .................................. 12 +13.2 Informative References ................................ 12 14 Author's Address ...................................... 12 -15 Intellectual Property Statement ....................... 12 +15 Intellectual Property Statement ....................... 13 16 Copyright Notice ...................................... 13 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 RFC 3031 [RFC3031] limits the MPLS architecture to downstream- assigned MPLS labels. To quote from RFC 3031: "In the MPLS architecture, the decision to bind a particular label L to a particular Forwarding Equivalence Class (FEC) F is made by the Label Switching Router (LSR) which is DOWNSTREAM with respect to that binding. The downstream LSR then informs the upstream LSR of the binding. Thus labels are "downstream-assigned", and label bindings are distributed in the "downstream to upstream" direction." - Upstream assignment of MPLS labels has been discussed and mentioned - before [RFC3353, MVPN]. However the architecture for upstream - assignment of MPLS labels and the associated procedures have not been - described. This document introduces the notion of upstream-assigned - MPLS labels to the MPLS architecture. The procedures for upstream - assignment of MPLS labels are described. + This document introduces the notion of upstream-assigned MPLS labels + to the MPLS architecture. The procedures for upstream assignment of + MPLS labels are described. RFC 3031 describes per-platform and per-interface label space. This document generalizes the latter to a "Context-Specific Label Space" and describes a "Neighbor Label Space" as an example of this. - upstream-assigned labels are always looked up in a context-specific + Upstream-assigned labels are always looked up in a context-specific label space. 3. Context-Specific Label Space RFC 3031 describes per-platform and per-interface label spaces. This document introduces the more general concept of a "Context-Specific - Label Space". A LSR may contain one or more context-specific label - spaces. In general, labels are looked up in the per-platform label - space unless something about the context determines that a label be - looked up in a particular context-specific label space. + Label Space". A LSR may maintain one or more context-specific label + spaces. In general, labels MUST be looked up in the per-platform + label space unless something about the context determines that a + label be looked up in a particular context-specific label space. One example of a context-specific label space is the per-interface label space discussed in RFC 3031. When a MPLS packet is received over a particular interface the top label of the packet may need to be looked up in the receiving interface's per-interface label space. In this case the receiving interface is the context of the packet. Whether MPLS packets received over a particular interface need to have their top labels looked up in a per-interface label space depends on some characteristic or configuration of the interface. @@ -123,24 +120,24 @@ When MPLS labels are upstream-assigned the context of a MPLS label L is provided by the LSR that assigns the label and binds the label to a FEC F for a Label Switched Path (LSP) LSP1. The LSR that assigns the label distributes the binding and context to a LSR Lr that then receives MPLS packets on LSP1 with label L. When Lr receives a MPLS packet on LSP1 it MUST be able to determine the context of this packet. An example of such a context is a Tunnel over which MPLS packets on - LSP1 may be received and in this case the top label of the MPLS - packet, after tunnel decapsulation, is looked up in a label space - that is specific to the root of the tunnel. This does imply that Lr - be able to determine the tunnel over which the packet was received. + LSP1 may be received. In this case the top label of the MPLS packet, + after tunnel decapsulation, is looked up in a label space that is + specific to the root of the tunnel. This does imply that Lr be able + to determine the tunnel over which the packet was received. Therefore, if the tunnel is a MPLS tunnel, penultimate-hop-popping (PHP) MUST be disabled for the tunnel. Another example of such a context is the neighbor from which MPLS packets on LSP1 may be received. In this case the top label of the MPLS packet, transmitted by the neighbor on LSP1, is looked up in a "Neighbor Specific Label Space". The above two examples are further described in section 7. @@ -154,50 +151,69 @@ 4. Upstream Label Assignment When two MPLS LSRs are adjacent in a MPLS label switched path (LSP) one of them can be termed an "upstream LSR" and the other a "downstream LSR" [RFC3031]. Consider two LSRs, Ru and Rd that have agreed to bind Label L to a FEC, F, for packets sent from Ru to Rd. Then with respect to this binding, Ru is the "upstream LSR", and Rd is the "downstream LSR"." - When the label binding for F is first made by Rd and distributed by - Rd to Ru, the binding is said to be "downstream-assigned". When the - label binding for F is first made by Ru and distributed by Ru to Rd, - the binding is said to be "upstream-assigned". + If the binding between L and F was made by Rd and advertised to Ru, + then the label binding is known as "downstream-assigned". RFC 3031 + only discusses downstream-assigned label bindings. + + If the binding between L and F was made by Ru and advertised to Rd, + then the label binding is known as "upstream-assigned". + + If the binding between L and F was made by a third party, say R3, and + then advertised to both Ru and Rd, we also refer to the label binding + as "upstream-assigned". An important observation about upstream-assigned labels is the following. When an upstream-assigned label L is at the top of the label stack, it must be looked up by an LSR which is not the LSR that assigned and distributed the label binding for L. Therefore an - upstream-assigned label must always be looked up in a context- + upstream-assigned label MUST always be looked up in a context- specific label space, as described in section 7. + We do not require any coordination between the upstream label + assignments and the downstream label assignments; a particular label + value may be upstream-assigned to one FEC and downstream-assigned to + a different FEC. + + The ability to use upstream-assigned labels is an OPTIONAL feature. + Upstream-assigned labels MUST NOT be used unless it is known that the + downstream LSR supports them. + + One use case of upstream-assigned labels is MPLS multicast and an + example of this is provided in section 9. + 4.1. Upstream-Assigned and Downstream-Assigned Labels It is possible that some LSRs on a LSP for FEC F, distribute downstream-assigned label bindings for FEC F, while other LSRs distribute upstream-assigned label bindings. It is possible for a LSR to distribute a downstream-assigned label binding for FEC F to its upstream adjacent LSR AND distribute an upstream-assigned label binding for FEC F to its downstream adjacent LSR. When two LSRs Ru and Rd are adjacent on an LSP for FEC F (with Ru being the upstream neighbor and Rd the downstream neighbor), either Ru distributes an upstream-assigned label binding for F to Rd, or else Rd distributes a downstream-assigned label binding to Ru, but NOT both. Whether upstream-assigned or downstream-assigned labels are to be used for a - particular FEC depends on the application using the LSP. Any - application which requires the use of upstream-assigned labels MUST - specify that explicitly, or else it is to be assumed that downstream- - assigned labels are used. An application on an LSR uses a label - distribution protocol to indicate to its peer LSRs whether a + particular FEC depends on the application using the LSP. + + Any application which requires the use of upstream-assigned labels + MUST specify that explicitly, or else it is to be assumed that + downstream-assigned labels are used. An application on an LSR uses a + label distribution protocol to indicate to its peer LSRs whether a particular label binding distributed by the LSR uses upstream- assigned or downstream-assigned label. Details of such procedures are outside the scope of this document. In some cases, the decision as to which is used for a particular application may be made by a configuration option. 5. Assigning Upstream-Assigned Labels The only requirement on an upstream LSR assigning upstream-assigned labels is that an upstream-assigned label must be unambiguous in the @@ -312,22 +328,24 @@ 4) The signaling protocol used to set up tunnel B identified B's root node as IP address X. 5) Packets sent through tunnels A and B may be carrying upstream- assigned labels. 6) Ru is the LSR that assigned the upstream-assigned labels mentioned in condition 5. - Under these conditions, Ru MUST use the same label space when - assigning the upstream-assigned labels. + If and only if these conditions hold, then Ru MUST use the same label + space when upstream-assigning labels for packets that travel through + tunnel A that it uses, when upstream-assigning labels for packets + that travel through tunnel B. Suppose that Rd is a node that belongs to tunnels A and B, but is not the root node of either tunnel. Then Rd may assume that the same upstream-assigned label space is used on both tunnels IF AND ONLY IF the signaling protocol used to set up tunnel A identified the root node as IP address X and the signaling protocol used to set up tunnel B identified the root node as the same IP address X. In addition, the protocol that is used for distributing the upstream- assigned label to be used over a particular tunnel MUST identify the @@ -418,38 +436,39 @@ address where the lowest 20 bits are equal. To avoid these conflicts the context label MUST be looked up in the context of the LAN interface on which the packet is received. A receiving LSR that receives a packet with a context label of Lc over LAN interface identified by X, MUST use the label space specific to X to lookup Lc. This determines the context to lookup the label below Lc in the label stack. 9. Usage of Upstream-Assigned Labels - A typical usage of upstream-assigned labels is when an upstream LSR - Ru is adjacent to several downstream LSRs in a LSP LSP1 - AND Ru is connected to via a multi-access media or tunnel - AND Ru wants to transmit a single copy of a MPLS packet on the LSP to - . In the case of a tunnel Ru can distribute an upstream- - assigned label L that is bound to the FEC for LSP1, to and - transmit a MPLS packet, the top label of which is L, on the tunnel. - In the case of a multi-access media Ru can distribute an upstream- - assigned label L that is bound to the FEC for LSP1, to and - transmit a MPLS packet, the top label of which is the context label - that identifies Ru, and the label immediately below is L, on the - multi-access media. Each of will then interpret this MPLS - packet in the context of Ru and forward it appropriately. This - implies that MUST all be able to support an Upstream - Neighbor Label Space for Ru and Ru MUST be able to determine this. - The mechanisms for determining this are specific to the application - that is using upstream-assigned labels and is outside the scope of - this document. + A typical use case of upstream-assigned labels is for MPLS multicast + and is described here for illustration. This use case arises when an + upstream LSR Ru is adjacent to several downstream LSRs in + a LSP LSP1 AND Ru is connected to via a multi-access + media or tunnel AND Ru wants to transmit a single copy of a MPLS + packet on the LSP to . In the case of a tunnel Ru can + distribute an upstream-assigned label L that is bound to the FEC for + LSP1, to and transmit a MPLS packet, the top label of + which is L, on the tunnel. In the case of a multi-access media Ru + can distribute an upstream-assigned label L that is bound to the FEC + for LSP1, to and transmit a MPLS packet, the top label of + which is the context label that identifies Ru, and the label + immediately below is L, on the multi-access media. Each of + will then interpret this MPLS packet in the context of Ru and forward + it appropriately. This implies that MUST all be able to + support an Upstream Neighbor Label Space for Ru and Ru MUST be able + to determine this. The mechanisms for determining this are specific + to the application that is using upstream-assigned labels and is + outside the scope of this document. 10. IANA Considerations This document has no actions for IANA. 11. Security Considerations The security considerations that apply to upstream-assigned labels and context labels are no different in kind than those that apply to downstream-assigned labels. @@ -460,47 +479,50 @@ considered here. Section 8 of this document describes a procedure which enables an LSR to automatically generate a unique context label for a LAN. This procedure assumes that the IP addresses of all the LSR interfaces on the LAN will be unique in their low-order 20 bits. If two LSRs whose IP addresses have the same low-order 20 bits are placed on the LAN, other LSRs are likely to misroute packets transmitted to the LAN by either of the two LSRs in question. + 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]. + 12. Acknowledgements Thanks to IJsbrand Wijnands's contribution, specifically for the text on which section 8 is based. 13. References 13.1. Normative References [RFC3031] "MPLS Architecture", E. Rosen, A. Viswanathan, R. Callon, RFC 3031. [RFC2119] "Key words for use in RFCs to Indicate Requirement [MPLS-MCAST-ENCAPS] T. Eckert, E. Rosen, R. Aggarwal, Y. Rekhter, - draft-ietf-mpls-multicast-encaps-08.txt + draft-ietf-mpls-multicast-encaps-10.txt 13.2. Informative References - [MVPN] E. Rosen, R. Aggarwal [Editors], Multicast in BGP/MPLS VPNs", - draft-ietf-l3vpn-2547bis-mcast-06.txt - - [RFC3353] D. Ooms, et. al., "Overview of IP Multicast in a Multi- - Protocol Label Switching (MPLS) Environment.", August 2002. - [RFC3032] E. Rosen, et. al., "MPLS Label Stack Encoding", January 2001. + [MPLS-SEC] L. fang, ed, "Security Framework for MPLS and GMPLS + Networks", draft-ietf-mpls-mpls-and-gmpls-security-framework-02.txt + 14. Author's Address Rahul Aggarwal Juniper Networks 1194 North Mathilda Ave. Sunnyvale, CA 94089 Email: rahul@juniper.net Yakov Rekhter Juniper Networks