--- 1/draft-ietf-mpls-upstream-label-06.txt 2008-07-11 01:12:16.000000000 +0200 +++ 2/draft-ietf-mpls-upstream-label-07.txt 2008-07-11 01:12:16.000000000 +0200 @@ -1,25 +1,25 @@ Network Working Group R. Aggarwal Internet Draft Juniper Networks Category: Standards Track -Expiration Date: December 2008 Y. Rekhter +Expiration Date: January 2009 Y. Rekhter Juniper Networks E. Rosen Cisco Systems, Inc. - June 05, 2008 + July 10, 2008 MPLS Upstream Label Assignment and Context-Specific Label Space - draft-ietf-mpls-upstream-label-06.txt + draft-ietf-mpls-upstream-label-07.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 @@ -49,24 +49,24 @@ 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 ......................... 7 8 Context Label on LANs ................................. 9 - 9 Usage of Upstream-Assigned Labels ..................... 10 + 9 Usage of Upstream-Assigned Labels ..................... 11 10 IANA Considerations ................................... 11 11 Security Considerations ............................... 11 -12 Acknowledgements ...................................... 11 +12 Acknowledgements ...................................... 12 13 References ............................................ 12 13.1 Normative References .................................. 12 13.2 Informative References ................................ 12 14 Author's Address ...................................... 12 15 Intellectual Property Statement ....................... 13 16 Copyright Notice ...................................... 13 1. Specification of requirements The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", @@ -394,59 +394,71 @@ Section 8 describes how the context label is assigned. Rd maintains a separate "Upstream Neighbor Label Space" for Ru. The "context" of this packet, i.e. Ru's upstream neighbor label space, in which L was reserved, is determined by Rd from the top context label and the interface on which the packet is received. The ether type in the data link frame is set to indicate that the top label is upstream- assigned. The second label in the stack is L. 8. Context Label on LANs - The procedure described below applies to LSRs using IPv4 and does not - apply to LSRs only using IPv6. A solution for IPv6 LSRs is outside - the scope of this document. - For a labeled packet with an ether type of 'upstream label assignment' the top label is used as the context. The context label value is assigned by the upstream LSR and advertised to the - downstream LSRs. Mechanisms for advertising the context label will - be provided by the label distribution protocol between the upstream - and downstream LSRs. The description of such a mechanism is outside - the scope of this document. + downstream LSRs. Mechanisms for advertising the context label will be + provided by the label distribution protocol between the upstream and + downstream LSRs. The description of such a mechanism is outside the + scope of this document. - The context label assigned by a LSR on a LAN interface MUST be unique - across all the context labels assigned by other LSRs on the same LAN. - Each LAN interface is normally configured with a primary IPv4 address - that is unique on that LAN. The host part of the IPv4 address, - identified by the network mask, is unique. If the IPv4 network mask - is greater then 12 bits, it is possible to map the remaining 20 bits - into an unique context label value. This enables the LSRs on the LAN - to assign an unique context label without the need for additional - configuration. To avoid assigning context label values that fall into - the reserved label space range [RFC3032], the value of the host part - of the IPv4 address is offset with 0x10, if this value is not greater + The context label assigned by an LSR for use on a particular LAN + interface MUST be unique across all the context labels assigned by + other LSRs for use on the same LAN. When a labeled packet is received + from the LAN, the context label MUST be looked up in the context of + the LAN interface on which the packet is received. + + This document provides two methods which an LSR can use to choose a + context label to advertise on a particular LAN. + + The first method requires that each LSR be provisioned with a 20-bit + context label for each LAN interface on which a context label is + required. It is then left to the provisioning system to make sure + that an assigned context label is unique across the corresponding + LAN. + + The second method allows the context labels to be auto-generated, but + is only applicable if each LSR on the LAN has an IPv4 address as its + primary IP address for the corresponding LAN interface. (If the LAN + contains LSRs that have only IPv6 addresses for the LAN interface, + then the first method is used.) + + Suppose that each LAN interface is configured with a primary IPv4 + address that is unique on that LAN. The host part of the IPv4 + address, identified by the network mask, is unique. If the IPv4 + network mask is greater then 12 bits, it is possible to map the + remaining 20 bits into a unique context label value. This enables the + LSRs on the LAN to automatically generate a unique context label. To + ensure that auto-generated context label values do not fall into the + reserved label space range [RFC3032], the value of the host part of + the IPv4 address is offset with 0x10, if this value is not greater then 0xFFFEF. Values of the host part of the IPv4 address greater - then 0xFFFEF are not allowed to be used as the context label. + then 0xFFFEF are not allowed to be used as context labels. Consider LSRs Rm (downstream) connected to Ru1 (upstream) on a LAN interface and to Ru2 (upstream) on a different LAN interface. Rm could receive a context label value derived from the LAN interface from Ru1 and from Ru2. It is possible that the context label values used by Ru1 and Ru2 are the same. This would occur if the LAN interfaces of both Ru1 and Ru2 are configured with a primary IPv4 - 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. + address where the lowest 20 bits are equal. However, this does not + create any ambiguity, as it has already been stated that the context + label MUST be looked up in the context of the LAN interface on which + the packet is received. 9. Usage of Upstream-Assigned Labels 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