draft-ietf-mpls-upstream-label-04.txt   draft-ietf-mpls-upstream-label-05.txt 
Network Working Group R. Aggarwal Network Working Group R. Aggarwal
Internet Draft Juniper Networks Internet Draft Juniper Networks
Category: Standards Track Category: Standards Track
Expiration Date: August 2008 Y. Rekhter Expiration Date: October 2008 Y. Rekhter
Juniper Networks Juniper Networks
E. Rosen E. Rosen
Cisco Systems, Inc. Cisco Systems, Inc.
February 22, 2008 April 30, 2008
MPLS Upstream Label Assignment and Context-Specific Label Space MPLS Upstream Label Assignment and Context-Specific Label Space
draft-ietf-mpls-upstream-label-04.txt draft-ietf-mpls-upstream-label-05.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware 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 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. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 2, line 18 skipping to change at page 2, line 18
2 Introduction .......................................... 2 2 Introduction .......................................... 2
3 Context-Specific Label Space .......................... 3 3 Context-Specific Label Space .......................... 3
4 Upstream Label Assignment ............................. 4 4 Upstream Label Assignment ............................. 4
4.1 Upstream-Assigned and Downstream-Assigned Labels ...... 5 4.1 Upstream-Assigned and Downstream-Assigned Labels ...... 5
5 Assigning Upstream-Assigned Labels .................... 5 5 Assigning Upstream-Assigned Labels .................... 5
6 Distributing Upstream-Assigned Labels ................. 6 6 Distributing Upstream-Assigned Labels ................. 6
7 Upstream Neighbor Label Space ......................... 6 7 Upstream Neighbor Label Space ......................... 6
8 Context Label on LANs ................................. 9 8 Context Label on LANs ................................. 9
9 Usage of Upstream-Assigned Labels ..................... 10 9 Usage of Upstream-Assigned Labels ..................... 10
10 IANA Considerations ................................... 10 10 IANA Considerations ................................... 10
11 Security Considerations ............................... 10 11 Security Considerations ............................... 11
12 Acknowledgements ...................................... 11 12 Acknowledgements ...................................... 11
13 References ............................................ 11 13 References ............................................ 11
13.1 Normative References .................................. 11 13.1 Normative References .................................. 11
13.2 Informative References ................................ 11 13.2 Informative References ................................ 11
14 Author's Address ...................................... 11 14 Author's Address ...................................... 12
15 Intellectual Property Statement ....................... 12 15 Intellectual Property Statement ....................... 12
16 Copyright Notice ...................................... 12 16 Copyright Notice ...................................... 13
1. Specification of requirements 1. Specification of requirements
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
2. Introduction 2. Introduction
RFC 3031 [RFC3031] limits the MPLS architecture to downstream- RFC 3031 [RFC3031] limits the MPLS architecture to downstream-
skipping to change at page 5, line 16 skipping to change at page 5, line 16
It is possible that some LSRs on a LSP for FEC F, distribute It is possible that some LSRs on a LSP for FEC F, distribute
downstream-assigned label bindings for FEC F, while other LSRs downstream-assigned label bindings for FEC F, while other LSRs
distribute upstream-assigned label bindings. It is possible for a LSR distribute upstream-assigned label bindings. It is possible for a LSR
to distribute a downstream-assigned label binding for FEC F to its to distribute a downstream-assigned label binding for FEC F to its
upstream adjacent LSR AND distribute an upstream-assigned label upstream adjacent LSR AND distribute an upstream-assigned label
binding for FEC F to its downstream adjacent LSR. When two LSRs Ru 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 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 neighbor and Rd the downstream neighbor), either Ru distributes an
upstream-assigned label binding for F to Rd, or else Rd distributes a upstream-assigned label binding for F to Rd, or else Rd distributes a
downstream-assigned label binding to Ru, but NOT both. How these downstream-assigned label binding to Ru, but NOT both. Whether
LSRs will determine which of the two is to be used is outside the upstream-assigned or downstream-assigned labels are to be used for a
scope of this document. 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 5. Assigning Upstream-Assigned Labels
The only requirement on an upstream LSR assigning upstream-assigned The only requirement on an upstream LSR assigning upstream-assigned
labels is that an upstream-assigned label must be unambiguous in the labels is that an upstream-assigned label must be unambiguous in the
context-specific label space in which the downstream LSR will look it context-specific label space in which the downstream LSR will look it
up. An upstream LSR which is the head end of multiple tunnels SHOULD up. An upstream LSR which is the head end of multiple tunnels SHOULD
by default assign the upstream-assigned labels, for all the LSPs by default assign the upstream-assigned labels, for all the LSPs
carried over these tunnels, from a single label space, which is carried over these tunnels, from a single label space, which is
common to all those tunnels. Further an upstream LSR which is the common to all those tunnels. Further an upstream LSR which is the
skipping to change at page 7, line 7 skipping to change at page 7, line 16
of a MPLS packet being processed is upstream-assigned and if yes, the of a MPLS packet being processed is upstream-assigned and if yes, the
"context" of this packet. How this determination is made depends on "context" of this packet. How this determination is made depends on
the mechanism that is used by Ru to transmit the MPLS packet with an the mechanism that is used by Ru to transmit the MPLS packet with an
upstream-assigned top label L, to Rd. upstream-assigned top label L, to Rd.
If Ru transmits this packet by encapsulating it in an IP or MPLS If Ru transmits this packet by encapsulating it in an IP or MPLS
tunnel, then the fact that L is upstream-assigned is determined by Rd tunnel, then the fact that L is upstream-assigned is determined by Rd
by the tunnel on which the packet is received. Whether a given tunnel by the tunnel on which the packet is received. Whether a given tunnel
can be used for transmitting MPLS packets with either downstream- can be used for transmitting MPLS packets with either downstream-
assigned or upstream assigned MPLS labels, or both, depends on the assigned or upstream assigned MPLS labels, or both, depends on the
tunnel type and is described in [MPLS-MCAST-ENCAPS]. There must be a tunnel type and is described in [MPLS-MCAST-ENCAPS]. When Rd receives
mechanism for Ru to inform Rd that a particular tunnel from Ru to Rd MPLS packets with a top label L on such a tunnel, it determines the
will be used by Ru for transmitting MPLS packets with upstream- "context" of this packet based on the tunnel that the packet is
assigned MPLS labels. The description of such a mechanism is outside received on. There must be a mechanism for Ru to inform Rd that a
the scope of this document. When Rd receives MPLS packets with a top particular tunnel from Ru to Rd will be used by Ru for transmitting
label L on such a tunnel, it determines the "context" of this packet MPLS packets with upstream-assigned MPLS labels. Such a mechanism
based on the tunnel that the packet is received on. will be provided by the label distribution protocol between Ru and Rd
and will likely require extensions to existing label distribution
protocols. The description of such a mechanism is outside the scope
of this document.
Rd maintains an "Upstream Neighbor Label Space" for upstream assigned Rd maintains an "Upstream Neighbor Label Space" for upstream assigned
labels, assigned by Ru. When Ru transmits MPLS packets the top label labels, assigned by Ru. When Ru transmits MPLS packets the top label
of which is upstream assigned over IP or MPLS tunnels, then Rd MUST of which is upstream assigned over IP or MPLS tunnels, then Rd MUST
be able to determine the root of these IP/MPLS tunnels. Rd MUST then be able to determine the root of these IP/MPLS tunnels. Rd MUST then
use a separate label space for each unique root. use a separate label space for each unique root.
The root is identified by the head-end IP address of the Tunnel. If The root is identified by the head-end IP address of the Tunnel. If
the same upstream router, Ru, uses different head-end IP addresses the same upstream router, Ru, uses different head-end IP addresses
for different tunnels then the downstream router, Rd, MUST maintain a for different tunnels then the downstream router, Rd, MUST maintain a
skipping to change at page 9, line 20 skipping to change at page 9, line 33
8. Context Label on LANs 8. Context Label on LANs
The procedure described below applies to LSRs using IPv4 and does not 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 apply to LSRs only using IPv6. A solution for IPv6 LSRs is outside
the scope of this document. the scope of this document.
For a labeled packet with an ether type of 'upstream label For a labeled packet with an ether type of 'upstream label
assignment' the top label is used as the context. The context label assignment' the top label is used as the context. The context label
value is assigned by the upstream LSR and advertised to the value is assigned by the upstream LSR and advertised to the
downstream LSRs. Mechanisms for advertising the context label are downstream LSRs. Mechanisms for advertising the context label will
outside the scope of this document. 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 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. across all the context labels assigned by other LSRs on the same LAN.
Each LAN interface is normally configured with a primary IPv4 address Each LAN interface is normally configured with a primary IPv4 address
that is unique on that LAN. The host part of the 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 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 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 into an unique context label value. This enables the LSRs on the LAN
to assign an unique context label without the need for additional to assign an unique context label without the need for additional
configuration. To avoid assigning context label values that fall into configuration. To avoid assigning context label values that fall into
skipping to change at page 11, line 19 skipping to change at page 11, line 38
13. References 13. References
13.1. Normative References 13.1. Normative References
[RFC3031] "MPLS Architecture", E. Rosen, A. Viswanathan, R. Callon, [RFC3031] "MPLS Architecture", E. Rosen, A. Viswanathan, R. Callon,
RFC 3031. RFC 3031.
[RFC2119] "Key words for use in RFCs to Indicate Requirement [RFC2119] "Key words for use in RFCs to Indicate Requirement
[MPLS-MCAST-ENCAPS] T. Eckert, E. Rosen, R. Aggarwal, Y. Rekhter, [MPLS-MCAST-ENCAPS] T. Eckert, E. Rosen, R. Aggarwal, Y. Rekhter,
draft-ietf-mpls-multicast-encaps-07.txt draft-ietf-mpls-multicast-encaps-08.txt
13.2. Informative References 13.2. Informative References
[MVPN] E. Rosen, R. Aggarwal [Editors], Multicast in BGP/MPLS VPNs", [MVPN] E. Rosen, R. Aggarwal [Editors], Multicast in BGP/MPLS VPNs",
draft-ietf-l3vpn-2547bis-mcast-06.txt draft-ietf-l3vpn-2547bis-mcast-06.txt
[RFC3353] D. Ooms, et. al., "Overview of IP Multicast in a Multi- [RFC3353] D. Ooms, et. al., "Overview of IP Multicast in a Multi-
Protocol Label Switching (MPLS) Environment.", August 2002. Protocol Label Switching (MPLS) Environment.", August 2002.
[RFC3032] E. Rosen, et. al., "MPLS Label Stack Encoding", January [RFC3032] E. Rosen, et. al., "MPLS Label Stack Encoding", January
 End of changes. 10 change blocks. 
19 lines changed or deleted 33 lines changed or added

This html diff was produced by rfcdiff 1.34. The latest version is available from http://tools.ietf.org/tools/rfcdiff/