draft-ietf-mpls-upstream-label-02.txt   draft-ietf-mpls-upstream-label-03.txt 
Network Working Group R. Aggarwal Network Working Group R. Aggarwal
Internet Draft Juniper Networks Internet Draft Juniper Networks
Expiration Date: September 2007
Y. Rekhter Y. Rekhter
Juniper Networks Juniper Networks
E. Rosen E. Rosen
Cisco Systems, Inc. Cisco Systems, Inc.
MPLS Upstream Label Assignment and Context Specific Label Space November 2007
draft-ietf-mpls-upstream-label-02.txt MPLS Upstream Label Assignment and Context-Specific Label Space
draft-ietf-mpls-upstream-label-03.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 1, line 41 skipping to change at page 1, line 42
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
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 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 ...... 4 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 ................. 5 6 Distributing Upstream-Assigned Labels ................. 6
7 Upstream Neighbor Label Space and Tunnel Label Space .. 6 7 Upstream Neighbor Label Space ......................... 6
8 Context Label on LANs ................................. 7 8 Context Label on LANs ................................. 9
9 Usage of Upstream Assigned Labels ..................... 8 9 Usage of Upstream-Assigned Labels ..................... 10
10 Acknowledgements ...................................... 8 10 IANA Considerations ................................... 10
11 References ............................................ 9 11 Security Considerations ............................... 10
11.1 Normative References .................................. 9 12 Acknowledgements ...................................... 11
11.2 Informative References ................................ 9 13 References ............................................ 11
12 Author Information .................................... 9 13.1 Normative References .................................. 11
13 Intellectual Property Statement ....................... 10 13.2 Informative References ................................ 11
14 Full Copyright Statement .............................. 10 14 Author Information .................................... 11
15 Intellectual Property Statement ....................... 12
16 Copyright Notice ...................................... 12
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 FEC F is made by the LSR which is DOWNSTREAM with to a particular Forwarding Equivalence Class (FEC) F is made by the
respect to that binding. The downstream LSR then informs the Label Switching Router (LSR) which is DOWNSTREAM with respect to that
upstream LSR of the binding. Thus labels are "downstream-assigned", binding. The downstream LSR then informs the upstream LSR of the
and label bindings are distributed in the "downstream to upstream" binding. Thus labels are "downstream-assigned", and label bindings
direction." are distributed in the "downstream to upstream" direction."
MPLS upstream label assignment has been discussed and mentioned Upstream assignment of MPLS labels has been discussed and mentioned
before [RFC3353, MVPN]. However the architecture for MPLS upstream before [RFC3353, MVPN]. However the architecture for upstream
label assignment and the associated procedures have not been assignment of MPLS labels and the associated procedures have not been
described. This document introduces the notion of upstream assigned described. This document introduces the notion of upstream-assigned
MPLS labels to the MPLS architecture. The procedures for upstream MPLS labels to the MPLS architecture. The procedures for upstream
MPLS label assignment are described. 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 contain one or more context-specific label
spaces. In general, labels are looked up in the per-platform label spaces. In general, labels are looked up in the per-platform label
space unless something about the context determines that a label be space unless something about the context determines that a label be
looked up in a particular context-specific label space. 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 determines the context of the In this case the receiving interface is the context of the packet.
packet. Whether MPLS packets received over a particular interface Whether MPLS packets received over a particular interface need to
need to have their top labels looked up in a per-interface have their top labels looked up in a per-interface label space
label space depends on some characteristic or configuration of the depends on some characteristic or configuration of the interface.
interface.
There may be more than one kind of context-specific label space. Per-interface label space [RFC3031] is an example of a context-
Context-specific label spaces can be used for downstream assigned specific label space used for downstream-assigned labels. Context-
labels or upstream assigned labels. Per-interface label space specific label spaces can also be used for upstream-assigned labels,
[RFC3031] is an example of a context-specific label space used for as described below.
downstream assigned labels.
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 LSP LSP1. The LSR that assigns the label distributes a FEC F for a Label Switched Path (LSP) LSP1. The LSR that assigns
the binding and context to a LSR Lr that then receives MPLS packets the label distributes the binding and context to a LSR Lr that then
on LSP1 with label L. When Lr receives a MPLS packet on LSP1 it MUST receives MPLS packets on LSP1 with label L. When Lr receives a MPLS
be able to determine the context of this packet. packet on LSP1 it MUST be able to determine the context of this
packet.
An example of such a context is a Tunnel over which MPLS packets on 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 and in this case the top label of the MPLS
packet is looked up in a "Tunnel Specific Label Space". This does packet, after tunnel decapsulation, is looked up in a label space
imply that Lr be able to determine the tunnel over which the packet that is specific to the root of the tunnel. This does imply that Lr
was received. If the tunnel is a MPLS tunnel, penultimate-hop-popping be able to determine the tunnel over which the packet was received.
(PHP) must be disabled for the tunnel. Another example of such a Therefore, if the tunnel is a MPLS tunnel, penultimate-hop-popping
context is the neighbor from which MPLS packets on LSP1 may be (PHP) MUST be disabled for the tunnel.
received and in this case the top label of the MPLS packet is looked
up in a "Neighbor Specific Label Space". These are further described Another example of such a context is the neighbor from which MPLS
in section 7. packets on LSP1 may be received. In this case the top label of the
MPLS packet, transmitted by the neighbor on LSP1, is looked up in a
"Neighbor Specific Label Space".
The above two examples are further described in section 7.
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 define
the notion of a MPLS label being used to establish a context, i.e. the notion of a MPLS label being used to establish a context, i.e.
identify a label space. identify a label space. A "context label" is one which identifies a
label table in which the label immediately below the context label
should be looked up. A context label carried as an outermost label
over a particular multi-access subnet/tunnel MUST be 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 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 Forwarding Equivalence Class (FEC), F, agreed to bind Label L to a FEC, F, for packets sent from Ru to Rd.
for packets sent from Ru to Rd. Then with respect to this binding, Then with respect to this binding, Ru is the "upstream LSR", and Rd
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 When the label binding for F is first made by Rd and distributed by
Rd to Ru, the binding is said to be "downstream assigned". When Rd to Ru, the binding is said to be "downstream-assigned". When the
the label binding for F is first made by Ru and distributed by Ru label binding for F is first made by Ru and distributed by Ru to Rd,
to Rd, the binding is said to be "upstream assigned". the binding is said to be "upstream-assigned".
An important observation is that the downstream LSR Rd that receives An important observation about upstream-assigned labels is the
MPLS packets with a top label L is not the LSR that assigns and following. When an upstream-assigned label L is at the top of the
distributes label L. Rd must use a context-specific label space to label stack, it must be looked up by an LSR which is not the LSR that
lookup label L as described in section 7. assigned and distributed the label binding for L. Therefore an
upstream-assigned label must always be looked up in a context-
specific label space, as described in section 7.
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. Two adjacent LSRs binding for FEC F to its downstream adjacent LSR. When two LSRs Ru
for a LSP that is bound to FEC F, MUST use either downstream assigned and Rd are adjacent on an LSP for FEC F (with Ru being the upstream
label distribution or upstream assigned label distribution, for FEC neighbor and Rd the downstream neighbor), either Ru distributes an
F, but NOT both. How these LSRs will determine which of the two is to upstream-assigned label binding for F to Rd, or else Rd distributes a
be used is outside the scope of this document. downstream-assigned label binding to Ru, but NOT both. How these
LSRs will determine which of the two is to be used is outside the
scope of this document.
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 from a single label by default assign the upstream-assigned labels, for all the LSPs
space which is common to all those tunnels. Further an upstream LSR carried over these tunnels, from a single label space, which is
which is the head of multiple tunnels SHOULD use the same IP address common to all those tunnels. Further an upstream LSR which is the
as the head identifier of these tunnels, provided that the head head of multiple tunnels SHOULD use the same IP address as the head
identifier of these tunnels is an IP address. The LSR could assign identifier of these tunnels, provided that the head identifier of
the same label value to both a downstream-assigned and an upstream- these tunnels includes an IP address. The LSR could assign the same
assigned label. The downstream LSR always looks up upstream assigned label value to both a downstream-assigned and an upstream-assigned
MPLS labels in a context-specific label space as described in section label. The downstream LSR always looks up upstream-assigned MPLS
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
Upstream-assigned label bindings MUST NOT be used unless it is known Upstream-assigned label bindings MUST NOT be used unless it is known
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.
skipping to change at page 6, line 11 skipping to change at page 6, line 28
assigned labels. In the former case a LSR distributes an upstream- assigned labels. In the former case a 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 that
it recognizes a particular FEC, makes an independent decision to bind it recognizes a particular FEC, makes an independent decision to bind
an upstream-assigned label to that FEC and to distribute that binding an upstream-assigned label to that FEC and to distribute that binding
to its label distribution peers. to its label distribution peers.
7. Upstream Neighbor Label Space and Tunnel 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 a MPLS packet being processed by LSR Rd is
upstream assigned, the label is looked up in a context-specific upstream-assigned, the label is looked up in a context-specific label
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 lookup a MPLS label which 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 of
a packet received from Ru or it may be exposed as the top label on a packet received from Ru or it may be exposed as the top label on
the label stack as a result of Rd processing such a packet. the label stack, as a result of Rd popping one or more labels off the
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 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. A given tunnel can be by the tunnel on which the packet is received. Whether a given tunnel
used for transmitting either downstream assigned MPLS packets or can be used for transmitting MPLS packets with either downstream-
upstream assigned MPLS packets, or both. There must be a mechanism assigned or upstream assigned MPLS labels, or both, depends on the
for Ru to inform Rd that a particular tunnel from Ru to Rd will be tunnel type and is described in [MPLS-MCAST-ENCAPS]. There must be a
used by Ru for transmitting MPLS packets with upstream assigned MPLS mechanism for Ru to inform Rd that a particular tunnel from Ru to Rd
labels. The description of such a mechanism is outside the scope of will be used by Ru for transmitting MPLS packets with upstream-
this document. When Rd receives MPLS packets with a top label L on assigned MPLS labels. The description of such a mechanism is outside
such a tunnel, it determines the "context" of this packet based on the scope of this document. When Rd receives MPLS packets with a top
the tunnel that the packet is received on. label L on such a tunnel, it determines the "context" of this packet
based on the tunnel that the packet is received on.
Rd may maintain a separate "Tunnel Label Space" for the tunnel or it Rd maintains an "Upstream Neighbor Label Space" for upstream assigned
may maintain an Upstream Neighbor Label Space" for all tunnels that labels, assigned by Ru. When Ru transmits MPLS packets the top label
have the same root. If Rd uses the "Upstream Neighbor Label Space" of which is upstream assigned over IP or MPLS tunnels, then Rd MUST
for upstream assigned MPLS packets transmitted by Ru to Rd, over IP be able to determine the root of these IP/MPLS tunnels. Rd MUST then
or MPLS tunnels, then Rd MUST be able to determine the root of these use a separate label space for each unique root.
IP/MPLS tunnels. Rd would then use a separate label space for each
unique root. 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
for different tunnels then the downstream router, Rd, MUST maintain a
different Upstream Neighbor Label Space for each such head-end IP
address.
Consider the following conditions:
1) Ru is the "root" of two tunnels, call them A and B.
2) IP address X is an IP address of Ru.
3) The signaling protocol used to set up tunnel A identified A's
root node as IP address X.
4) The signaling protocol used to set up tunnel B identified B's
root node as IP address X.
5) Packets sent through tunnels A and B may be carrying upstream-
assigned labels.
6) Ru is the LSR that assigned the upstream-assigned labels
mentioned in condition 5.
Under these conditions, Ru MUST use the same label space when
assigning the upstream-assigned labels.
Suppose that Rd is a node that belongs to tunnels A and B, but is not
the root node of either tunnel. Then Rd may assume that the same
upstream-assigned label space is used on both tunnels IF AND ONLY IF
the signaling protocol used to set up tunnel A identified the root
node as IP address X and the signaling protocol used to set up tunnel
B identified the root node as the same IP address X.
In addition, the protocol that is used for distributing the upstream-
assigned label to be used over a particular tunnel MUST identify the
"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.
Implementors must take note of this, even if the tunnel setup
protocol is different from the protocol that is used for distributing
the upstream-assigned label to be used over the tunnel.
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
the tunnel. For P2P tunnels, the intention is that the headend of the
tunnel is the "root". For P2MP or MP2MP tunnels, one can always
identify one node as being the "root" of the tunnel.
Some tunnels may be set up by configuration, rather than by
signaling. In these cases, the IP address of the root of the tunnel
must be configured.
Some tunnels may not even require configuration, e.g., a GRE tunnel
can be "created" just by encapsulating packets and transmitting them.
In such a case the IP 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 a 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 [MPLS-MCAST-ENCAPS] and b) The context for L, from the source address
in the IP header. in the IP 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 because if L is upstream assigned in [MPLS-MCAST-ENCAPS]. This is possible because if L is upstream-
then [MPLS-MCAST-ENCAPS] uses a different ether type in the data link assigned then [MPLS-MCAST-ENCAPS] uses a different ether type in the
frame. However this is not sufficient for Rd to determine the context data link frame. However this is not sufficient for Rd to determine
of this packet. In order for Rd to determine the context of this the context of this packet. In order for Rd to determine the context
packet, Ru encapsulates the packet, in a one hop MPLS tunnel. This of this packet, Ru encapsulates the packet, in a one hop MPLS tunnel.
tunnel uses an MPLS context label that is assigned by Ru. Section 8 This tunnel uses an MPLS context label that is assigned by Ru.
describes how the context label is assigned. Rd maintains a separate Section 8 describes how the context label is assigned. Rd maintains
"Upstream Neighbor Label Space" for Ru. The "context" of this packet, a separate "Upstream Neighbor Label Space" for Ru. The "context" of
i.e. Ru's upstream neighbor label space, in which L was reserved, is this packet, i.e. Ru's upstream neighbor label space, in which L was
determined by Rd from the top context label and the interface on reserved, is determined by Rd from the top context label and the
which the packet is received. The ether type in the data link frame interface on which the packet is received. The ether type in the data
is set to indicate that the top label is upstream assigned. The link frame is set to indicate that the top label is upstream-
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
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
skipping to change at page 8, line 7 skipping to change at page 9, line 32
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
the reserved label space range [RFC 3032], the value of the host is the reserved label space range [RFC3032], the value of the host part
offset with 0x10 if the host is not greater then 0xFFFEF. Host values of the IPv4 address is offset with 0x10, if this value is not greater
greater then 0xFFFEF are not allowed to be used as the context label. then 0xFFFEF. Values of the host part of the IPv4 address greater
then 0xFFFEF are not allowed to be used as the context label.
Consider LSRs Rm (middle) connected to Ru (upstream) on a LAN Consider LSRs Rm (downstream) connected to Ru1 (upstream) on a LAN
interface and to Rd (downstream) 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 Rd and from Ru. It is possible that the context label values from Ru1 and from Ru2. It is possible that the context label values
used by Ru and Rd 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 Ru and Rd 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. 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 identifier on which the packet is received. A receiving LSR interface on which the packet is received. A receiving LSR that
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 on 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 usage of upstream-assigned labels is when an upstream LSR
Ru is adjacent to more than downstream LSRs <Rd1...Rdn> in a LSP LSP1 Ru is adjacent to several downstream LSRs <Rd1...Rdn> in a LSP LSP1
AND Ru is connected to <Rd1...Rdn> via a multi-access media or tunnel 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 packet on the LSP to AND Ru wants to transmit a single copy of a MPLS packet on the LSP to
<Rd1...Rdn>. In this case Ru can distribute an upstream assigned <Rd1...Rdn>. In the case of a tunnel Ru can distribute an upstream-
label L that is bound to the FEC for LSP1, to <Rd1..Rdn> and transmit assigned label L that is bound to the FEC for LSP1, to <Rd1..Rdn> and
a MPLS packet, the top label of which is L, on the multi-access media transmit a MPLS packet, the top label of which is L, on the tunnel.
or tunnel. Each of <Rd1..Rdn> will then interpret this MPLS packet in In the case of a multi-access media Ru can distribute an upstream-
the context of Ru and forward it appropriately. This implies that assigned label L that is bound to the FEC for LSP1, to <Rd1..Rdn> and
<Rd1..Rdn> MUST all be able to support an Upstream Neighbor Label transmit a MPLS packet, the top label of which is the context label
Space for Ru and Ru MUST be able to determine this. The mechanisms that identifies Ru, and the label immediately below is L, on the
for determining this are specific to the application that is using multi-access media. Each of <Rd1..Rdn> will then interpret this MPLS
upstream assigned labels and is outside the scope of this document. packet in the context of Ru and forward it appropriately. This
implies that <Rd1..Rdn> MUST all be able to support an Upstream
Neighbor Label Space for Ru and Ru MUST be able to determine this.
The mechanisms for determining this are specific to the application
that is using upstream-assigned labels and is outside the scope of
this document.
10. Acknowledgements 10. IANA Considerations
This document has no actions for IANA.
11. Security Considerations
The security considerations that apply to upstream-assigned labels
and context labels are no different in kind than those that apply to
downstream-assigned labels.
Note that procedures for distributing upstream-assigned labels and/or
context labels are not within the scope of this document. Therefore
the security considerations that may apply to such procedures are not
considered here.
Section 8 of this document describes a procedure which enables an LSR
to automatically generate a unique context label for a LAN. This
procedure assumes that the IP addresses of all the LSR interfaces on
the LAN will be unique in their low-order 20 bits. If two LSRs whose
IP addresses have the same low-order 20 bits are placed on the LAN,
other LSRs are likely to misroute packets transmitted to the LAN by
either of the two LSRs in question.
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.
11. References 13. References
11.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-codepoint-01.txt draft-ietf-mpls-multicast-encaps-06.txt
11.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-l3vn-2547bis-mcast-02.txt draft-ietf-l3vpn-2547bis-mcast-05.txt
12. Author Information [RFC3353] D. Ooms, et. al., "Overview of IP Multicast in a Multi-
Protocol Label Switching (MPLS) Environment.", August 2002.
[RFC3032] E. Rosen, et. al., "MPLS Label Stack Encoding", January
2001.
14. Author Information
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 Email: erosen@cisco.com
13. Intellectual Property Statement 15. Intellectual Property Statement
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.
skipping to change at page 10, line 29 skipping to change at page 12, line 33
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 ietf-
ipr@ietf.org. ipr@ietf.org.
14. Full Copyright Statement 16. Copyright Notice
Copyright (C) The IETF Trust (2007). This document is subject to the Copyright (C) The IETF Trust (2007).
rights, licenses and restrictions contained in BCP 78, and except as
set forth therein, the authors retain all their rights. 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 This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
 End of changes. 57 change blocks. 
164 lines changed or deleted 272 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/