draft-ietf-mpls-upstream-label-05.txt   draft-ietf-mpls-upstream-label-06.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: October 2008 Y. Rekhter Expiration Date: December 2008 Y. Rekhter
Juniper Networks Juniper Networks
E. Rosen E. Rosen
Cisco Systems, Inc. Cisco Systems, Inc.
April 30, 2008 June 05, 2008
MPLS Upstream Label Assignment and Context-Specific Label Space 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 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 14 skipping to change at page 2, line 14
Table of Contents Table of Contents
1 Specification of requirements ......................... 2 1 Specification of requirements ......................... 2
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 ......................... 7
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 ................................... 11
11 Security Considerations ............................... 11 11 Security Considerations ............................... 11
12 Acknowledgements ...................................... 11 12 Acknowledgements ...................................... 11
13 References ............................................ 11 13 References ............................................ 12
13.1 Normative References .................................. 11 13.1 Normative References .................................. 12
13.2 Informative References ................................ 11 13.2 Informative References ................................ 12
14 Author's Address ...................................... 12 14 Author's Address ...................................... 12
15 Intellectual Property Statement ....................... 12 15 Intellectual Property Statement ....................... 13
16 Copyright Notice ...................................... 13 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-
assigned MPLS labels. To quote from RFC 3031: assigned MPLS labels. To quote from RFC 3031:
"In the MPLS architecture, the decision to bind a particular label L "In the MPLS architecture, the decision to bind a particular label L
to a particular Forwarding Equivalence Class (FEC) F is made by the to a particular Forwarding Equivalence Class (FEC) F is made by the
Label Switching Router (LSR) which is DOWNSTREAM with respect to that Label Switching Router (LSR) which is DOWNSTREAM with respect to that
binding. The downstream LSR then informs the upstream LSR of the binding. The downstream LSR then informs the upstream LSR of the
binding. Thus labels are "downstream-assigned", and label bindings binding. Thus labels are "downstream-assigned", and label bindings
are distributed in the "downstream to upstream" direction." are distributed in the "downstream to upstream" direction."
Upstream assignment of MPLS labels has been discussed and mentioned This document introduces the notion of upstream-assigned MPLS labels
before [RFC3353, MVPN]. However the architecture for upstream to the MPLS architecture. The procedures for upstream assignment of
assignment of MPLS labels and the associated procedures have not been MPLS labels are described.
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 RFC 3031 describes per-platform and per-interface label space. This
document generalizes the latter to a "Context-Specific Label Space" document generalizes the latter to a "Context-Specific Label Space"
and describes a "Neighbor Label Space" as an example of this. 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. label space.
3. Context-Specific Label Space 3. Context-Specific Label Space
RFC 3031 describes per-platform and per-interface label spaces. This RFC 3031 describes per-platform and per-interface label spaces. This
document introduces the more general concept of a "Context-Specific document introduces the more general concept of a "Context-Specific
Label Space". A LSR may contain one or more context-specific label Label Space". A LSR may maintain one or more context-specific label
spaces. In general, labels are looked up in the per-platform label spaces. In general, labels MUST be looked up in the per-platform
space unless something about the context determines that a label be label space unless something about the context determines that a
looked up in a particular context-specific label space. label be looked up in a particular context-specific label space.
One example of a context-specific label space is the per-interface One example of a context-specific label space is the per-interface
label space discussed in RFC 3031. When a MPLS packet is received 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 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. be looked up in the receiving interface's per-interface label space.
In this case the receiving interface is the context of the packet. In this case the receiving interface is the context of the packet.
Whether MPLS packets received over a particular interface need to Whether MPLS packets received over a particular interface need to
have their top labels looked up in a per-interface label space have their top labels looked up in a per-interface label space
depends on some characteristic or configuration of the interface. depends on some characteristic or configuration of the interface.
skipping to change at page 4, line 6 skipping to change at page 3, line 49
When MPLS labels are upstream-assigned the context of a MPLS label L 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 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 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 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 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 on LSP1 it MUST be able to determine the context of this
packet. packet.
An example of such a context is a Tunnel over which MPLS packets on 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 LSP1 may be received. In this case the top label of the MPLS packet,
packet, after tunnel decapsulation, is looked up in a label space after tunnel decapsulation, is looked up in a label space that is
that is specific to the root of the tunnel. This does imply that Lr specific to the root of the tunnel. This does imply that Lr be able
be able to determine the tunnel over which the packet was received. to determine the tunnel over which the packet was received.
Therefore, if the tunnel is a MPLS tunnel, penultimate-hop-popping Therefore, if the tunnel is a MPLS tunnel, penultimate-hop-popping
(PHP) MUST be disabled for the tunnel. (PHP) MUST be disabled for the tunnel.
Another example of such a context is the neighbor from which MPLS 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 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 MPLS packet, transmitted by the neighbor on LSP1, is looked up in a
"Neighbor Specific Label Space". "Neighbor Specific Label Space".
The above two examples are further described in section 7. The above two examples are further described in section 7.
skipping to change at page 4, line 37 skipping to change at page 4, line 33
4. Upstream Label Assignment 4. Upstream Label Assignment
When two MPLS LSRs are adjacent in a MPLS label switched path (LSP) 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 one of them can be termed an "upstream LSR" and the other a
"downstream LSR" [RFC3031]. Consider two LSRs, Ru and Rd that have "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. 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 Then with respect to this binding, Ru is the "upstream LSR", and Rd
is the "downstream LSR"." is the "downstream LSR"."
When the label binding for F is first made by Rd and distributed by If the binding between L and F was made by Rd and advertised to Ru,
Rd to Ru, the binding is said to be "downstream-assigned". When the then the label binding is known as "downstream-assigned". RFC 3031
label binding for F is first made by Ru and distributed by Ru to Rd, only discusses downstream-assigned label bindings.
the binding is said to be "upstream-assigned".
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 An important observation about upstream-assigned labels is the
following. When an upstream-assigned label L is at the top of 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 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 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. 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 4.1. Upstream-Assigned and Downstream-Assigned Labels
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. Whether downstream-assigned label binding to Ru, but NOT both. Whether
upstream-assigned or downstream-assigned labels are to be used for a upstream-assigned or downstream-assigned labels are to be used for a
particular FEC depends on the application using the LSP. Any particular FEC depends on the application using the LSP.
application which requires the use of upstream-assigned labels MUST
specify that explicitly, or else it is to be assumed that downstream- Any application which requires the use of upstream-assigned labels
assigned labels are used. An application on an LSR uses a label MUST specify that explicitly, or else it is to be assumed that
distribution protocol to indicate to its peer LSRs whether a 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- particular label binding distributed by the LSR uses upstream-
assigned or downstream-assigned label. Details of such procedures are assigned or downstream-assigned label. Details of such procedures are
outside the scope of this document. In some cases, the decision as to 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 which is used for a particular application may be made by a
configuration option. 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
skipping to change at page 8, line 11 skipping to change at page 8, line 24
4) The signaling protocol used to set up tunnel B identified B's 4) The signaling protocol used to set up tunnel B identified B's
root node as IP address X. root node as IP address X.
5) Packets sent through tunnels A and B may be carrying upstream- 5) Packets sent through tunnels A and B may be carrying upstream-
assigned labels. assigned labels.
6) Ru is the LSR that assigned the upstream-assigned labels 6) Ru is the LSR that assigned the upstream-assigned labels
mentioned in condition 5. mentioned in condition 5.
Under these conditions, Ru MUST use the same label space when If and only if these conditions hold, then Ru MUST use the same label
assigning the upstream-assigned labels. 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 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 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 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 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 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. B identified the root node as the same IP address X.
In addition, the protocol that is used for distributing the upstream- In addition, the protocol that is used for distributing the upstream-
assigned label to be used over a particular tunnel MUST identify the assigned label to be used over a particular tunnel MUST identify the
skipping to change at page 10, line 21 skipping to change at page 10, line 37
address where the lowest 20 bits are equal. To avoid these conflicts 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 the context label MUST be looked up in the context of the LAN
interface on which the packet is received. A receiving LSR that interface on which the packet is received. A receiving LSR that
receives a packet with a context label of Lc over LAN interface 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. 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 This determines the context to lookup the label below Lc in the label
stack. stack.
9. Usage of Upstream-Assigned Labels 9. Usage of Upstream-Assigned Labels
A typical usage of upstream-assigned labels is when an upstream LSR A typical use case of upstream-assigned labels is for MPLS multicast
Ru is adjacent to several downstream LSRs <Rd1...Rdn> in a LSP LSP1 and is described here for illustration. This use case arises when an
AND Ru is connected to <Rd1...Rdn> via a multi-access media or tunnel upstream LSR Ru is adjacent to several downstream LSRs <Rd1...Rdn> in
AND Ru wants to transmit a single copy of a MPLS packet on the LSP to a LSP LSP1 AND Ru is connected to <Rd1...Rdn> via a multi-access
<Rd1...Rdn>. In the case of a tunnel Ru can distribute an upstream- media or tunnel AND Ru wants to transmit a single copy of a MPLS
assigned label L that is bound to the FEC for LSP1, to <Rd1..Rdn> and packet on the LSP to <Rd1...Rdn>. In the case of a tunnel Ru can
transmit a MPLS packet, the top label of which is L, on the tunnel. distribute an upstream-assigned label L that is bound to the FEC for
In the case of a multi-access media Ru can distribute an upstream- LSP1, to <Rd1..Rdn> and transmit a MPLS packet, the top label of
assigned label L that is bound to the FEC for LSP1, to <Rd1..Rdn> and which is L, on the tunnel. In the case of a multi-access media Ru
transmit a MPLS packet, the top label of which is the context label can distribute an upstream-assigned label L that is bound to the FEC
that identifies Ru, and the label immediately below is L, on the for LSP1, to <Rd1..Rdn> and transmit a MPLS packet, the top label of
multi-access media. Each of <Rd1..Rdn> will then interpret this MPLS which is the context label that identifies Ru, and the label
packet in the context of Ru and forward it appropriately. This immediately below is L, on the multi-access media. Each of <Rd1..Rdn>
implies that <Rd1..Rdn> MUST all be able to support an Upstream will then interpret this MPLS packet in the context of Ru and forward
Neighbor Label Space for Ru and Ru MUST be able to determine this. it appropriately. This implies that <Rd1..Rdn> MUST all be able to
The mechanisms for determining this are specific to the application support an Upstream Neighbor Label Space for Ru and Ru MUST be able
that is using upstream-assigned labels and is outside the scope of to determine this. The mechanisms for determining this are specific
this document. to the application that is using upstream-assigned labels and is
outside the scope of this document.
10. IANA Considerations 10. IANA Considerations
This document has no actions for IANA. This document has no actions for IANA.
11. Security Considerations 11. Security Considerations
The security considerations that apply to upstream-assigned labels The security considerations that apply to upstream-assigned labels
and context labels are no different in kind than those that apply to and context labels are no different in kind than those that apply to
downstream-assigned labels. downstream-assigned labels.
skipping to change at page 11, line 24 skipping to change at page 11, line 33
considered here. considered here.
Section 8 of this document describes a procedure which enables an LSR Section 8 of this document describes a procedure which enables an LSR
to automatically generate a unique context label for a LAN. This to automatically generate a unique context label for a LAN. This
procedure assumes that the IP addresses of all the LSR interfaces on 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 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, 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 other LSRs are likely to misroute packets transmitted to the LAN by
either of the two LSRs in question. 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 12. Acknowledgements
Thanks to IJsbrand Wijnands's contribution, specifically for the text Thanks to IJsbrand Wijnands's contribution, specifically for the text
on which section 8 is based. on which section 8 is based.
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-08.txt draft-ietf-mpls-multicast-encaps-10.txt
13.2. Informative References 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 [RFC3032] E. Rosen, et. al., "MPLS Label Stack Encoding", January
2001. 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 14. Author's Address
Rahul Aggarwal Rahul Aggarwal
Juniper Networks Juniper Networks
1194 North Mathilda Ave. 1194 North Mathilda Ave.
Sunnyvale, CA 94089 Sunnyvale, CA 94089
Email: rahul@juniper.net Email: rahul@juniper.net
Yakov Rekhter Yakov Rekhter
Juniper Networks Juniper Networks
 End of changes. 21 change blocks. 
61 lines changed or deleted 83 lines changed or added

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