draft-ietf-mpls-upstream-label-07.txt   rfc5331.txt 
Network Working Group R. Aggarwal Network Working Group R. Aggarwal
Internet Draft Juniper Networks Request for Comments: 5331 Juniper Networks
Category: Standards Track Category: Standards Track Y. Rekhter
Expiration Date: January 2009 Y. Rekhter
Juniper Networks Juniper Networks
E. Rosen E. Rosen
Cisco Systems, Inc. Cisco Systems, Inc.
August 2008
July 10, 2008
MPLS Upstream Label Assignment and Context-Specific Label Space MPLS Upstream Label Assignment and Context-Specific Label Space
draft-ietf-mpls-upstream-label-07.txt Status of This Memo
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
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at This document specifies an Internet standards track protocol for the
http://www.ietf.org/shadow.html. Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Abstract Abstract
RFC 3031 limits the MPLS architecture to downstream-assigned MPLS RFC 3031 limits the MPLS architecture to downstream-assigned MPLS
labels. This document introduces the notion of upstream-assigned labels. This document introduces the notion of upstream-assigned
MPLS labels. It describes the procedures for upstream MPLS label MPLS labels. It describes the procedures for upstream MPLS label
assignment and introduces the concept of a "Context-Specific Label assignment and introduces the concept of a "Context-Specific Label
Space". Space".
Table of Contents Table of Contents
1 Specification of requirements ......................... 2 1. Introduction ....................................................2
2 Introduction .......................................... 2 2. Specification of Requirements ...................................2
3 Context-Specific Label Space .......................... 3 3. Context-Specific Label Space ....................................2
4 Upstream Label Assignment ............................. 4 4. Upstream Label Assignment .......................................3
4.1 Upstream-Assigned and Downstream-Assigned Labels ...... 5 4.1. Upstream-Assigned and Downstream-Assigned Labels ...........4
5 Assigning Upstream-Assigned Labels .................... 5 5. Assigning Upstream-Assigned Labels ..............................5
6 Distributing Upstream-Assigned Labels ................. 6 6. Distributing Upstream-Assigned Labels ...........................5
7 Upstream Neighbor Label Space ......................... 7 7. Upstream Neighbor Label Space ...................................6
8 Context Label on LANs ................................. 9 8. Context Label on LANs ...........................................9
9 Usage of Upstream-Assigned Labels ..................... 11 9. Usage of Upstream-Assigned Labels ..............................10
10 IANA Considerations ................................... 11 10. Security Considerations .......................................10
11 Security Considerations ............................... 11 11. Acknowledgements ..............................................11
12 Acknowledgements ...................................... 12 12. References ....................................................11
13 References ............................................ 12 12.1. Normative References .....................................11
13.1 Normative References .................................. 12 12.2. Informative References ...................................11
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",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
2. Introduction 1. 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."
skipping to change at page 3, line 17 skipping to change at page 2, line 27
This document introduces the notion of upstream-assigned MPLS labels This document introduces the notion of upstream-assigned MPLS labels
to the MPLS architecture. The procedures for upstream assignment of to the MPLS architecture. The procedures for upstream assignment of
MPLS labels are described. 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.
2. 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].
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 maintain one or more context-specific label Label Space". An LSR may maintain one or more context-specific label
spaces. In general, labels MUST be looked up in the per-platform spaces. In general, labels MUST be looked up in the per-platform
label space unless something about the context determines that a label space unless something about the context determines that a
label be 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 an 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.
Per-interface label space [RFC3031] is an example of a context- Per-interface label space [RFC3031] is an example of a context-
specific label space used for downstream-assigned labels. Context- specific label space used for downstream-assigned labels. Context-
specific label spaces can also be used for upstream-assigned labels, specific label spaces can also be used for upstream-assigned labels,
as described below. as described below.
When MPLS labels are upstream-assigned the context of a MPLS label L When MPLS labels are upstream-assigned, the context of an MPLS label
is provided by the LSR that assigns the label and binds the label to L is provided by the LSR that assigns the label and binds the label
a FEC F for a Label Switched Path (LSP) LSP1. The LSR that assigns to a FEC F for a Label Switched Path (LSP) LSP1. The LSR that
the label distributes the binding and context to a LSR Lr that then assigns the label distributes the binding and context to an LSR Lr
receives MPLS packets on LSP1 with label L. When Lr receives a MPLS that then receives MPLS packets on LSP1 with label L. When Lr
packet on LSP1 it MUST be able to determine the context of this receives an MPLS packet on LSP1, it MUST be able to determine the
packet. context of this 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. In this case the top label of the MPLS packet, LSP1 may be received. In this case, the top label of the MPLS
after tunnel decapsulation, is looked up in a label space that is packet, after tunnel decapsulation, is looked up in a label space
specific to the root of the tunnel. This does imply that Lr be able that is specific to the root of the tunnel. This does imply that Lr
to determine the tunnel over which the packet was received. be able 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 an 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.
There may be other sorts of contexts as well. For instance, we define There may be other sorts of contexts as well. For instance, we
the notion of a MPLS label being used to establish a context, i.e. define the notion of an MPLS label being used to establish a context,
identify a label space. A "context label" is one which identifies a i.e., identify a label space. A "context label" is one that
label table in which the label immediately below the context label identifies a label table in which the label immediately below the
should be looked up. A context label carried as an outermost label context label should be looked up. A context label carried as an
over a particular multi-access subnet/tunnel MUST be unique within outermost label over a particular multi-access subnet/tunnel MUST be
the scope of that subnet/tunnel. unique within the scope of that subnet/tunnel.
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 an 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"."
If the binding between L and F was made by Rd and advertised to Ru, 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 then the label binding is known as "downstream-assigned". RFC 3031
only discusses downstream-assigned label bindings. only discusses downstream-assigned label bindings.
If the binding between L and F was made by Ru and advertised to Rd, If the binding between L and F was made by Ru and advertised to Rd,
then the label binding is known as "upstream-assigned". 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 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 then advertised to both Ru and Rd, we also refer to the label binding
as "upstream-assigned". 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 that 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 We do not require any coordination between the upstream label
assignments and the downstream label assignments; a particular label assignments and the downstream label assignments; a particular label
value may be upstream-assigned to one FEC and downstream-assigned to value may be upstream-assigned to one FEC and downstream-assigned to
a different FEC. a different FEC.
The ability to use upstream-assigned labels is an OPTIONAL feature. The ability to use upstream-assigned labels is an OPTIONAL feature.
Upstream-assigned labels MUST NOT be used unless it is known that the Upstream-assigned labels MUST NOT be used unless it is known that the
downstream LSR supports them. downstream LSR supports them.
One use case of upstream-assigned labels is MPLS multicast and an One use case of upstream-assigned labels is MPLS multicast, and an
example of this is provided in section 9. 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 an 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 an
to distribute a downstream-assigned label binding for FEC F to its LSR to distribute a downstream-assigned label binding for FEC F to
upstream adjacent LSR AND distribute an upstream-assigned label its 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. particular FEC depends on the application using the LSP.
Any application which requires the use of upstream-assigned labels Any application that requires the use of upstream-assigned labels
MUST specify that explicitly, or else it is to be assumed that MUST specify that explicitly, or else it is to be assumed that
downstream-assigned labels are used. An application on an LSR uses a downstream-assigned labels are used. An application on an LSR uses a
label distribution protocol to indicate to its peer LSRs whether 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
outside the scope of this document. In some cases, the decision as to are outside the scope of this document. In some cases, the decision
which is used for a particular application may be made by a as to 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
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 that is the headend 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 that is the
head of multiple tunnels SHOULD use the same IP address as the head head of multiple tunnels SHOULD use the same IP address as the head
identifier of these tunnels, provided that the head identifier of identifier of these tunnels, provided that the head identifier of
these tunnels includes an IP address. The LSR could assign the same these tunnels includes an IP address. The LSR could assign the same
label value to both a downstream-assigned and an upstream-assigned label value to both a downstream-assigned and an upstream-assigned
label. The downstream LSR always looks up upstream-assigned MPLS label. The downstream LSR always looks up upstream-assigned MPLS
labels in a context-specific label space as described in section 7. labels in a context-specific label space as described in Section 7.
An entry for the upstream-assigned labels is not created in the An entry for the upstream-assigned labels is not created in the
Incoming Label Map (ILM) [RFC3031] at the upstream LSR as these Incoming Label Map (ILM) [RFC3031] at the upstream LSR as these
labels are not incoming labels. Instead an upstream label is an labels are not incoming labels. Instead, an upstream label is an
outgoing label, with respect to the upstream LSR, for MPLS packets outgoing label, with respect to the upstream LSR, for MPLS packets
transmitted on the MPLS LSP in which the upstream LSR is adjacent to transmitted on the MPLS LSP in which the upstream LSR is adjacent to
the downstream LSR. Hence an upstream label is part of a Next Hop the downstream LSR. Hence, an upstream label is part of a Next Hop
Label Forwarding Entry (NHLFE) at the upstream LSR. Label Forwarding Entry (NHLFE) at the upstream LSR.
When Ru advertises a binding of label L for FEC F to Rd, it creates a When Ru advertises a binding of label L for FEC F to Rd, it creates a
NHLFE entry corresponding to L. This NHLFE entry results in imposing NHLFE entry corresponding to L. This NHLFE entry results in imposing
the label L on the MPLS label stack of the packet forwarded using the the label L on the MPLS label stack of the packet forwarded using the
NHLFE entry. If Ru is a transit router on the LSP for FEC F, it NHLFE entry. If Ru is a transit router on the LSP for FEC F, it
binds the ILM for the LSP to this NHLFE. If Ru is an ingress router binds the ILM for the LSP to this NHLFE. If Ru is an ingress router
on the LSP for FEC F, it binds the FEC to the NHLFE entry. on the LSP for FEC F, it binds the FEC to the NHLFE entry.
6. Distributing Upstream-Assigned Labels 6. Distributing Upstream-Assigned Labels
skipping to change at page 6, line 39 skipping to change at page 5, line 51
that the downstream LSR supports them. How this is known is outside that the downstream LSR supports them. How this is known is outside
the scope of this document. the scope of this document.
MPLS upstream label assignment requires a label distribution protocol MPLS upstream label assignment requires a label distribution protocol
to distribute the binding from the upstream LSR to the downstream to distribute the binding from the upstream LSR to the downstream
LSR. Considerations that pertain to a label distribution protocol LSR. Considerations that pertain to a label distribution protocol
that are described in [RFC3031] apply. that are described in [RFC3031] apply.
The distribution of the upstream-assigned labels is similar to either The distribution of the upstream-assigned labels is similar to either
the ordered LSP control or independent LSP control of the downstream- the ordered LSP control or independent LSP control of the downstream-
assigned labels. In the former case a LSR distributes an upstream- assigned labels. In the former case, an LSR distributes an upstream-
assigned label binding for a FEC F if it is either (a) the ingress assigned label binding for a FEC F if it is either (a) the ingress
LSR for FEC F, or (b) if it has already received an upstream label LSR for FEC F, or (b) if it has already received an upstream label
binding for that FEC from its adjacent upstream LSR for FEC F, or (c) binding for that FEC from its adjacent upstream LSR for FEC F, or (c)
if it has received a request for a downstream label binding from its if it has received a request for a downstream label binding from its
upstream adjacent LSR. In the latter case each LSR, upon noting that upstream adjacent LSR. In the latter case, each LSR, upon noting
it recognizes a particular FEC, makes an independent decision to bind that it recognizes a particular FEC, makes an independent decision to
an upstream-assigned label to that FEC and to distribute that binding bind an upstream-assigned label to that FEC and to distribute that
to its label distribution peers. binding to its label distribution peers.
7. Upstream Neighbor Label Space 7. Upstream Neighbor Label Space
If the top label of a MPLS packet being processed by LSR Rd is If the top label of an MPLS packet being processed by LSR Rd is
upstream-assigned, the label is looked up in a context-specific label upstream-assigned, the label is looked up in a context-specific label
space, not in a per-platform label space. space, not in a per-platform label space.
Rd uses a context-specific label space that it maintains for Ru to Rd uses a context-specific label space that it maintains for Ru to
"reserve" MPLS labels assigned by Ru. Hence if Ru distributes an "reserve" MPLS labels assigned by Ru. Hence, if Ru distributes an
upstream assigned label binding L for FEC F to Rd, then Rd reserves L upstream-assigned label binding L for FEC F to Rd, then Rd reserves L
in the separate ILM for Ru's context-specific label space. This is in the separate ILM for Ru's context-specific label space. This is
the ILM that Rd uses to lookup a MPLS label which is upstream- the ILM that Rd uses to look up an MPLS label that is upstream-
assigned by Ru. This label may be the top label on the label stack of assigned by Ru. This label may be the top label on the label stack
a packet received from Ru or it may be exposed as the top label on of a packet received from Ru or it may be exposed as the top label on
the label stack, as a result of Rd popping one or more labels off the the label stack, as a result of Rd popping one or more labels off the
label stack, from such a packet. label stack, from such a packet.
This implies that Rd MUST be able to determine whether the top label This implies that Rd MUST be able to determine whether the top label
of a MPLS packet being processed is upstream-assigned and if yes, the of an MPLS packet being processed is upstream-assigned and, if yes,
"context" of this packet. How this determination is made depends on the "context" of this packet. How this determination is made depends
the mechanism that is used by Ru to transmit the MPLS packet with an on the mechanism that is used by Ru to transmit the MPLS packet with
upstream-assigned top label L, to Rd. an 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
can be used for transmitting MPLS packets with either downstream- tunnel can be used for transmitting MPLS packets with either
assigned or upstream assigned MPLS labels, or both, depends on the downstream-assigned or upstream-assigned MPLS labels, or both,
tunnel type and is described in [MPLS-MCAST-ENCAPS]. When Rd receives depends on the tunnel type and is described in [RFC5332]. When Rd
MPLS packets with a top label L on such a tunnel, it determines the receives MPLS packets with a top label L on such a tunnel, it
"context" of this packet based on the tunnel that the packet is determines the "context" of this packet based on the tunnel on which
received on. There must be a mechanism for Ru to inform Rd that a the packet is received. There must be a mechanism for Ru to inform
particular tunnel from Ru to Rd will be used by Ru for transmitting Rd that a particular tunnel from Ru to Rd will be used by Ru for
MPLS packets with upstream-assigned MPLS labels. Such a mechanism transmitting MPLS packets with upstream-assigned MPLS labels. Such a
will be provided by the label distribution protocol between Ru and Rd mechanism will be provided by the label distribution protocol between
and will likely require extensions to existing label distribution Ru and Rd and will likely require extensions to existing label
protocols. The description of such a mechanism is outside the scope distribution protocols. The description of such a mechanism is
of this document. 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
different Upstream Neighbor Label Space for each such head-end IP a different Upstream Neighbor Label Space for each such head-end IP
address. address.
Consider the following conditions: Consider the following conditions:
1) Ru is the "root" of two tunnels, call them A and B. 1) Ru is the "root" of two tunnels, call them A and B.
2) IP address X is an IP address of Ru. 2) IP address X is an IP address of Ru.
3) The signaling protocol used to set up tunnel A identified A's 3) The signaling protocol used to set up tunnel A identified A's
root node as IP address X. root node as IP address X.
skipping to change at page 8, line 26 skipping to change at page 7, line 37
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.
If and only if these conditions hold, then Ru MUST use the same label If and only if these conditions hold, then Ru MUST use the same label
space when upstream-assigning labels for packets that travel through space when upstream-assigning labels for packets that travel through
tunnel A that it uses, when upstream-assigning labels for packets tunnel A that it uses when upstream-assigning labels for packets that
that travel through tunnel B. 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
"assigner" using the same IP address that is used, by the protocol "assigner" using the same IP address that is used by the protocol
that sets up the tunnel, to identify the root node of the tunnel. that sets up the tunnel to identify the root node of the tunnel.
Implementors must take note of this, even if the tunnel setup Implementors must take note of this, even if the tunnel setup
protocol is different from the protocol that is used for distributing protocol is different from the protocol that is used for distributing
the upstream-assigned label to be used over the tunnel. the upstream-assigned label to be used over the tunnel.
The precise set of procedures for identifying the IP address of the The precise set of procedures for identifying the IP address of the
root of the tunnel depend, of course, on the protocol used to set up root of the tunnel depend, of course, on the protocol used to set up
the tunnel. For P2P tunnels, the intention is that the headend of the the tunnel. For Point-to-Point (P2P) tunnels, the intention is that
tunnel is the "root". For P2MP or MP2MP tunnels, one can always the headend of the tunnel is the "root". For Point-to-Multipoint
(P2MP) or Multipoint-to-Multipoint (MP2MP) tunnels, one can always
identify one node as being the "root" of the tunnel. identify one node as being the "root" of the tunnel.
Some tunnels may be set up by configuration, rather than by Some tunnels may be set up by configuration, rather than by
signaling. In these cases, the IP address of the root of the tunnel signaling. In these cases, the IP address of the root of the tunnel
must be configured. must be configured.
Some tunnels may not even require configuration, e.g., a GRE tunnel Some tunnels may not even require configuration, e.g., a Generic
can be "created" just by encapsulating packets and transmitting them. Routing Encapsulation (GRE) tunnel can be "created" just by
In such a case the IP address of the root is considered to be the IP encapsulating packets and transmitting them. In such a case, the IP
source address of the encapsulated packets. address of the root is considered to be the IP source address of the
encapsulated packets.
If the tunnel on which Rd receives MPLS packets with a top label L is If the tunnel on which Rd receives MPLS packets with a top label L is
a MPLS tunnel, then Rd determines a) That L is upstream-assigned and an MPLS tunnel, then Rd determines a) that L is upstream-assigned and
b) The context for L, from the labels above L in the label stack. b) the context for L, from the labels above L in the label stack.
Note that one or more of these labels may also be upstream-assigned Note that one or more of these labels may also be upstream-assigned
labels. labels.
If the tunnel on which Rd receives MPLS packets with a top label L is If the tunnel on which Rd receives MPLS packets with a top label L is
an IP/GRE tunnel then Rd determines a) That L is upstream-assigned an IP/GRE tunnel, then Rd determines a) that L is upstream-assigned
[MPLS-MCAST-ENCAPS] and b) The context for L, from the source address [RFC5332] and b) the context for L, from the source address in the IP
in the IP header. header.
When Ru and Rd are adjacent to each other on a multi-access data link When Ru and Rd are adjacent to each other on a multi-access data link
media, if Ru would transmit the packet, with top label L, by media, if Ru would transmit the packet, with top label L, by
encapsulating it in a data link frame, then whether L is upstream- encapsulating it in a data link frame, then whether L is upstream-
assigned or downstream assigned can be determined by Rd as described assigned or downstream assigned can be determined by Rd, as described
in [MPLS-MCAST-ENCAPS]. This is possible because if L is upstream- in [RFC5332]. This is possible because if L is upstream-assigned,
assigned then [MPLS-MCAST-ENCAPS] uses a different ether type in the then [RFC5332] uses a different ether type in the data link frame.
data link frame. However this is not sufficient for Rd to determine However, this is not sufficient for Rd to determine the context of
the context of this packet. In order for Rd to determine the context this packet. In order for Rd to determine the context of this
of this packet, Ru encapsulates the packet, in a one hop MPLS tunnel. packet, Ru encapsulates the packet in a one-hop MPLS tunnel. This
This tunnel uses an MPLS context label that is assigned by Ru. tunnel uses an MPLS context label that is assigned by Ru. Section 8
Section 8 describes how the context label is assigned. Rd maintains describes how the context label is assigned. Rd maintains a separate
a separate "Upstream Neighbor Label Space" for Ru. The "context" of "Upstream Neighbor Label Space" for Ru. The "context" of this
this packet, i.e. Ru's upstream neighbor label space, in which L was 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 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 interface on which the packet is received. The ether type in the
link frame is set to indicate that the top label is upstream- data link frame is set to indicate that the top label is upstream-
assigned. The second label in the stack is L. assigned. The second label in the stack is L.
8. Context Label on LANs 8. Context Label on LANs
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 will be downstream LSRs. Mechanisms for advertising the context label will
provided by the label distribution protocol between the upstream and be provided by the label distribution protocol between the upstream
downstream LSRs. The description of such a mechanism is outside the and downstream LSRs. The description of such a mechanism is outside
scope of this document. the scope of this document.
The context label assigned by an LSR for use on a particular LAN The context label assigned by an LSR for use on a particular LAN
interface MUST be unique across all the context labels assigned by 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 other LSRs for use on the same LAN. When a labeled packet is
from the LAN, the context label MUST be looked up in the context of received from the LAN, the context label MUST be looked up in the
the LAN interface on which the packet is received. context of the LAN interface on which the packet is received.
This document provides two methods which an LSR can use to choose a This document provides two methods that an LSR can use to choose a
context label to advertise on a particular LAN. context label to advertise on a particular LAN.
The first method requires that each LSR be provisioned with a 20-bit 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 context label for each LAN interface on which a context label is
required. It is then left to the provisioning system to make sure required. It is then left to the provisioning system to make sure
that an assigned context label is unique across the corresponding that an assigned context label is unique across the corresponding
LAN. LAN.
The second method allows the context labels to be auto-generated, but 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 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 primary IP address for the corresponding LAN interface. (If the LAN
contains LSRs that have only IPv6 addresses for the LAN interface, contains LSRs that have only IPv6 addresses for the LAN interface,
then the first method is used.) then the first method is used.)
Suppose that each LAN interface is configured with a primary IPv4 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 that is unique on that LAN. The host part of the IPv4
address, identified by the network mask, is unique. If 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 network mask is greater than 12 bits, it is possible to map the
remaining 20 bits into a unique context label value. This enables the remaining 20 bits into a unique context label value. This enables
LSRs on the LAN to automatically generate a unique context label. To the LSRs on the LAN to automatically generate a unique context label.
ensure that auto-generated context label values do not fall into the To ensure that auto-generated context label values do not fall into
reserved label space range [RFC3032], the value of the host part of the reserved label space range [RFC3032], the value of the host part
the IPv4 address is offset with 0x10, if this value is not greater 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 than 0xFFFEF. Values of the host part of the IPv4 address greater
then 0xFFFEF are not allowed to be used as context labels. than 0xFFFEF are not allowed to be used as context labels.
Consider LSRs Rm (downstream) connected to Ru1 (upstream) on a LAN Consider LSR Rm (downstream) connected to Ru1 (upstream) on a LAN
interface and to Ru2 (upstream) on a different LAN interface. Rm interface and to Ru2 (upstream) on a different LAN interface. Rm
could receive a context label value derived from the LAN interface could receive a context label value derived from the LAN interface
from Ru1 and from Ru2. It is possible that the context label values 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 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 interfaces of both Ru1 and Ru2 are configured with a primary IPv4
address where the lowest 20 bits are equal. However, this does not address where the lowest 20 bits are equal. However, this does not
create any ambiguity, as it has already been stated that the context 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 label MUST be looked up in the context of the LAN interface on which
the packet is received. the packet is received.
9. Usage of Upstream-Assigned Labels 9. Usage of Upstream-Assigned Labels
A typical use case of upstream-assigned labels is for MPLS multicast A typical use case of upstream-assigned labels is for MPLS multicast
and is described here for illustration. This use case arises when an and is described here for illustration. This use case arises when an
upstream LSR Ru is adjacent to several downstream LSRs <Rd1...Rdn> in upstream LSR Ru is adjacent to several downstream LSRs <Rd1...Rdn> in
a LSP LSP1 AND Ru is connected to <Rd1...Rdn> via a multi-access an LSP, LSP1 AND Ru is connected to <Rd1...Rdn> via a multi-access
media or tunnel AND Ru wants to transmit a single copy of a MPLS media or tunnel, AND Ru wants to transmit a single copy of an MPLS
packet on the LSP to <Rd1...Rdn>. In the case of a tunnel Ru can packet on the LSP to <Rd1...Rdn>. In the case of a tunnel, Ru can
distribute an upstream-assigned label L that is bound to the FEC for distribute an upstream-assigned label L that is bound to the FEC for
LSP1, to <Rd1..Rdn> and transmit a MPLS packet, the top label of LSP1, to <Rd1..Rdn> and transmit an MPLS packet, the top label of
which is L, on the tunnel. In the case of a multi-access media Ru 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 can distribute an upstream-assigned label L that is bound to the FEC
for LSP1, to <Rd1..Rdn> and transmit a MPLS packet, the top label of for LSP1, to <Rd1..Rdn> and transmit an MPLS packet, the top label of
which is the context label that identifies Ru, and the label which is the context label that identifies Ru, and the label
immediately below is L, on the multi-access media. Each of <Rd1..Rdn> immediately below is L, on the multi-access media. Each of
will then interpret this MPLS packet in the context of Ru and forward <Rd1..Rdn> will then interpret this MPLS packet in the context of Ru
it appropriately. This implies that <Rd1..Rdn> MUST all be able to and forward it appropriately. This implies that <Rd1..Rdn> MUST all
support an Upstream Neighbor Label Space for Ru and Ru MUST be able be able to support an Upstream Neighbor Label Space for Ru and Ru
to determine this. The mechanisms for determining this are specific MUST be able to determine this. The mechanisms for determining this
to the application that is using upstream-assigned labels and is are specific to the application that is using upstream-assigned
outside the scope of this document. labels and is outside the scope of this document.
10. IANA Considerations
This document has no actions for IANA.
11. Security Considerations 10. 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.
Note that procedures for distributing upstream-assigned labels and/or Note that procedures for distributing upstream-assigned labels and/or
context labels are not within the scope of this document. Therefore context labels are not within the scope of this document. Therefore,
the security considerations that may apply to such procedures are not the security considerations that may apply to such procedures are not
considered here. considered here.
Section 8 of this document describes a procedure which enables an LSR Section 8 of this document describes a procedure that 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 More detailed discussion of security issues that are relevant in the
context of MPLS and GMPLS, including security threats, related context of MPLS and GMPLS, including security threats, related
defensive techniques, and the mechanisms for detection and reporting, defensive techniques, and the mechanisms for detection and reporting,
are discussed in "Security Framework for MPLS and GMPLS Networks are discussed in "Security Framework for MPLS and GMPLS Networks
[MPLS-SEC]. [MPLS-SEC].
12. Acknowledgements 11. 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 12. References
13.1. Normative References 12.1. Normative References
[RFC3031] "MPLS Architecture", E. Rosen, A. Viswanathan, R. Callon, [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol
RFC 3031. Label Switching Architecture", RFC 3031, January 2001.
[RFC2119] "Key words for use in RFCs to Indicate Requirement [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
[MPLS-MCAST-ENCAPS] T. Eckert, E. Rosen, R. Aggarwal, Y. Rekhter, Requirement Levels", BCP 14, RFC 2119, March 1997.
draft-ietf-mpls-multicast-encaps-10.txt
13.2. Informative References [RFC5332] Eckert, T., Rosen, E., Aggarwal, R., and Y. Rekhter, "MPLS
Multicast Encpsulations", RFC 5332, August 2008.
[RFC3032] E. Rosen, et. al., "MPLS Label Stack Encoding", January 12.2. Informative References
2001.
[MPLS-SEC] L. fang, ed, "Security Framework for MPLS and GMPLS [RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y.,
Networks", draft-ietf-mpls-mpls-and-gmpls-security-framework-02.txt Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack
Encoding", RFC 3032, January 2001.
14. Author's Address [MPLS-SEC] Fang, L., Ed., "Security Framework for MPLS and GMPLS
Networks", Work in Progress, July 2008.
Authors' Addresses
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
1194 North Mathilda Ave. 1194 North Mathilda Ave.
Sunnyvale, CA 94089 Sunnyvale, CA 94089
Email: yakov@juniper.net
EMail: yakov@juniper.net
Eric C. Rosen Eric C. Rosen
Cisco Systems, Inc. Cisco Systems, Inc.
1414 Massachusetts Avenue 1414 Massachusetts Avenue
Boxborough, MA 01719 Boxborough, MA 01719
Email: erosen@cisco.com
15. Intellectual Property Statement EMail: erosen@cisco.com
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79. found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf- this standard. Please address the information to the IETF at
ipr@ietf.org. ietf-ipr@ietf.org.
16. Copyright Notice
Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
 End of changes. 78 change blocks. 
225 lines changed or deleted 222 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/