draft-ietf-mpls-ldp-upstream-00.txt   draft-ietf-mpls-ldp-upstream-01.txt 
Network Working Group R. Aggarwal Network Working Group R. Aggarwal
Internet Draft Juniper Networks Internet Draft Juniper Networks
Expiration Date: September 2006 Expiration Date: September 2007
J. L. Le Roux J. L. Le Roux
France Telecom France Telecom
MPLS Upstream Label Assignment for LDP MPLS Upstream Label Assignment for LDP
draft-ietf-mpls-ldp-upstream-00.txt draft-ietf-mpls-ldp-upstream-01.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 2, line 10 skipping to change at page 2, line 10
This document describes procedures for distributing upstream-assigned This document describes procedures for distributing upstream-assigned
labels for Label Distribution Protocol (LDP). It also describes how labels for Label Distribution Protocol (LDP). It also describes how
these procedures can be used for avoiding branch LSR traffic these procedures can be used for avoiding branch LSR traffic
replication on a LAN for LDP point-to-multipoint (P2MP)LSPs. replication on a LAN for LDP point-to-multipoint (P2MP)LSPs.
Table of Contents Table of Contents
1 Specification of requirements ......................... 2 1 Specification of requirements ......................... 2
2 Introduction .......................................... 2 2 Introduction .......................................... 2
3 LDP Upstream Label Assignment Capability .............. 3 3 LDP Upstream Label Assignment Capability .............. 3
4 Distributing Upstream-Assigned Labels in LDP .......... 4 4 Distributing Upstream-Assigned Labels in LDP .......... 3
4.1 Procedures ............................................ 4 4.1 Procedures ............................................ 4
5 LDP Tunnel Identifier Exchange ........................ 5 5 LDP Tunnel Identifier Exchange ........................ 5
6 LDP Point-to-Multipoint LSPs on a LAN ................. 6 6 LDP Point-to-Multipoint LSPs on a LAN ................. 6
7 Acknowledgements ...................................... 7 7 Acknowledgements ...................................... 8
8 References ............................................ 7 8 References ............................................ 8
8.1 Normative References .................................. 7 8.1 Normative References .................................. 8
8.2 Informative References ................................ 8 8.2 Informative References ................................ 9
9 Author Information .................................... 8 9 Author Information .................................... 9
10 Intellectual Property Statement ....................... 8 10 Intellectual Property Statement ....................... 9
11 Full Copyright Statement .............................. 9 11 Full Copyright Statement .............................. 10
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
This document describes procedures for distributing upstream-assigned This document describes procedures for distributing upstream-assigned
skipping to change at page 2, line 43 skipping to change at page 3, line 4
described in [MPLS-UPSTREAM]. described in [MPLS-UPSTREAM].
This document describes extensions to LDP that a LSR can use to This document describes extensions to LDP that a LSR can use to
advertise to its neighboring LSRs whether the LSR supports upstream advertise to its neighboring LSRs whether the LSR supports upstream
label assignment. label assignment.
This document also describes extensions to LDP to distribute This document also describes extensions to LDP to distribute
upstream-assigned labels. upstream-assigned labels.
The usage of MPLS upstream label assignment using LDP for avoiding The usage of MPLS upstream label assignment using LDP for avoiding
branch LSR traffic replication on a LAN for LDP P2MP LSPs [LDP-P2MP1, branch LSR traffic replication on a LAN for LDP P2MP LSPs [MLDP] is
LDP-P2MP2] is also described. also described.
3. LDP Upstream Label Assignment Capability 3. LDP Upstream Label Assignment Capability
According to [MPLS-UPSTREAM], upstream-assigned label bindings MUST According to [MPLS-UPSTREAM], upstream-assigned label bindings MUST
NOT be used unless it is known that a downstream LSR supports them. NOT be used unless it is known that a downstream LSR supports them.
This implies that there MUST be a mechanism to enable a LSR to adver- This implies that there MUST be a mechanism to enable a LSR to
tise to its LDP neighbor LSR(s) its support of upstream-assigned advertise to its LDP neighbor LSR(s) its support of upstream-assigned
labels. labels.
A new optional parameter, the LDP Capability TLV, is introduced to A new Capability Parameter, the LDP Upstream Label Assignment
allow LDP peers to exchange capabilities as part of LDP Initializa- Capability, is introduced to allow an LDP peer to exchange with its
tion messages. This TLV contains one or more sub-TLVs, each to sig- peers, its support of upstream label assignment. This parameter
nal a specific capability. LDP Capability TLV and detailed procedures follows the format and procedures for exchanging Capability
for supporting LDP Capability signaling will be described in a sepa- Parameters defined in [LDP-CAP].
rate document.
A Upstream Label Assignment Capability sub-TLV is introduced to sig-
nal a LSR's support of upstream label assignment, to its LDP peers.
This sub-TLV is carried in the LDP Capability TLV.
Following is the format of the LDP Capability TLV:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1|0| Capability TLV (TBD) | Length (= 4) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sub-TLVs... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Following is the format of the Upstream Label Assignment Capability Following is the format of the LDP Upstream Label Assignment
sub-TLV: Capability Parameter:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Upstream Lbl Ass Cap = 1 | Length (= 4) | |1|0| Upstream Lbl Ass Cap(IANA)| Length (= 5) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1| Reserved |
+-+-+-+-+-+-+-+-+
If a LSR includes the Upstream Label Assignment Capability sub-TLV in If a LSR includes the Upstream Label Assignment Capability in LDP
LDP Initialization Messages it implies that the LSR is capable of Initialization Messages it implies that the LSR is capable of both
both distributing upstream-assigned label bindings and receiving distributing upstream-assigned label bindings and receiving upstream-
upstream-assigned label bindings. Reserved bits MUST be set to zero assigned label bindings. The reserved bits MUST be set to zero on
on transmission and MUST be ignored on receipt. transmission and ignored on receipt. The Upstream Label Assignment
Capability Parameter can be exchanged only in LDP initialization
messages.
4. Distributing Upstream-Assigned Labels in LDP 4. Distributing Upstream-Assigned Labels in LDP
An optional LDP TLV, Upstream-Assigned Label Request TLV, is intro- An optional LDP TLV, Upstream-Assigned Label Request TLV, is
duced. This TLV MUST be carried in a Label Request message if an introduced. This TLV MUST be carried in a Label Request message if
upstream-assigned label is being requested. an upstream-assigned label is being requested.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|0| Upstream Ass Lbl Req (TBD)| Length | |0|0| Upstream Ass Lbl Req (TBD)| Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
An optional LDP TLV, Upstream-Assigned Label TLV is introduced to An optional LDP TLV, Upstream-Assigned Label TLV is introduced to
skipping to change at page 4, line 41 skipping to change at page 4, line 31
| Label | | Label |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Label Label
This is a 20-bit label value as specified in [RFC3032] represented as This is a 20-bit label value as specified in [RFC3032] represented as
a 20-bit number in a 4 octet field. a 20-bit number in a 4 octet field.
4.1. Procedures 4.1. Procedures
Procedures for Label Mapping, Label Request, Label Abort, Label With- Procedures for Label Mapping, Label Request, Label Abort, Label
draw and Label Release follow [RFC3036] other than the modifications Withdraw and Label Release follow [RFC3036] other than the
pointed out in this section. modifications pointed out in this section.
A LDP LSR MUST NOT distribute the Upstream Assigned Label TLV to a A LDP LSR MUST NOT distribute the Upstream Assigned Label TLV to a
neighboring LSR if the neighboring LSR had not previously advertised neighboring LSR if the neighboring LSR had not previously advertised
the Upstream Label Assignment Capability in its LDP Initialization the Upstream Label Assignment Capability in its LDP Initialization
messages. A LDP LSR MUST NOT send the Upstream Assigned Label messages. A LDP LSR MUST NOT send the Upstream Assigned Label
Request TLV to a neighboring LSR if the neighboring LSR had not pre- Request TLV to a neighboring LSR if the neighboring LSR had not
viously advertised the Upstream Label Assignment Capability in its previously advertised the Upstream Label Assignment Capability in its
LDP Initialization messages. LDP Initialization messages.
As described in [MPLS-UPSTREAM] the distribution of upstream-assigned As described in [MPLS-UPSTREAM] the distribution of upstream-assigned
labels is similar to either ordered LSP control or independent LSP labels is similar to either ordered LSP control or independent LSP
control of the downstream assigned labels. control of the downstream assigned labels.
When the label distributed in a Label Mapping message is an upstream- When the label distributed in a Label Mapping message is an upstream-
assigned label, the Upstream Assigned Label TLV MUST be included in assigned label, the Upstream Assigned Label TLV MUST be included in
the Label Mapping message. When a LSR receives a Label Mapping mes- the Label Mapping message. When a LSR receives a Label Mapping
sage with an Upstream Assigned Label TLV and if it does not recognize message with an Upstream Assigned Label TLV and it does not recognize
the TLV, it MUST generate a Notification message with a status code the TLV, it MUST generate a Notification message with a status code
of "Unknown TLV" [RFC3036]. If it does recognize the TLV but is of "Unknown TLV" [RFC3036]. If it does recognize the TLV but is
unable to process the upstream label, it MUST generate a Notification unable to process the upstream label, it MUST generate a Notification
message with a status code of "No Label Resources". If the Label Map- message with a status code of "No Label Resources". If the Label
ping message was generated in response to a Label Request message, Mapping message was generated in response to a Label Request message,
the Label Request message MUST contain an Upstream Assigned Label the Label Request message MUST contain an Upstream Assigned Label
Request TLV. A LSR that generates an upstream assigned label request Request TLV. A LSR that generates an upstream assigned label request
to a neighbor LSR, for a given FEC, MUST NOT send a downstream label to a neighbor LSR, for a given FEC, MUST NOT send a downstream label
mapping to the neighbor LSR for that FEC unless it withdraws the mapping to the neighbor LSR for that FEC unless it withdraws the
upstream-assigned label binding. Similarly if a LSR generates a down- upstream-assigned label binding. Similarly if a LSR generates a
stream assigned label request to a neighbor LSR, for a given FEC, it downstream assigned label request to a neighbor LSR, for a given FEC,
MUST NOT send an upstream label mapping to that LSR for that FEC, it MUST NOT send an upstream label mapping to that LSR for that FEC,
unless it aborts the downstream assigned label request. unless it aborts the downstream assigned label request.
The Upstream Assigned Label TLV may be optionally included in Label The Upstream Assigned Label TLV may be optionally included in Label
Withdraw and Label Release messages that withdraw/release a particu- Withdraw and Label Release messages that withdraw/release a
lar upstream assigned label binding. particular upstream assigned label binding.
5. LDP Tunnel Identifier Exchange 5. LDP Tunnel Identifier Exchange
As described in [MPLS-UPSTREAM] an upstream LSR Ru MAY transmit a As described in [MPLS-UPSTREAM] an upstream LSR Ru MAY transmit a
MPLS packet, the top label of which (L) is upstream-assigned, to a MPLS packet, the top label of which (L) is upstream-assigned, to a
downstream LSR Rd, by encapsulating it in an IP or MPLS tunnel. In downstream LSR Rd, by encapsulating it in an IP or MPLS tunnel. In
this case the fact that L is upstream-assigned is determined by Rd by this case the fact that L is upstream-assigned is determined by Rd by
the tunnel on which the packet is received. There must be a mechanism the tunnel on which the packet is received. There must be a mechanism
for Ru to inform Rd that a particular tunnel from Ru to Rd will be for Ru to inform Rd that a particular tunnel from Ru to Rd will be
used by Ru for transmitting MPLS packets with upstream-assigned MPLS used by Ru for transmitting MPLS packets with upstream-assigned MPLS
labels. labels.
When LDP is used for upstream label assignment, the Interface ID TLV When LDP is used for upstream label assignment, the Interface ID TLV
[RFC3472] is used for signaling the Tunnel Identifier. If Ru uses an [RFC3472] is used for signaling the Tunnel Identifier. If Ru uses an
IP or MPLS tunnel to transmit MPLS packets with upstream assigned IP or MPLS tunnel to transmit MPLS packets with upstream assigned
labels to Rd, Ru MUST include the Interface ID TLV in the Label Map- labels to Rd, Ru MUST include the Interface ID TLV in the Label
ping messages along with the Upstream Assigned Label TLV. Two new Mapping messages along with the Upstream Assigned Label TLV. Three
Interface ID TLVs are introduced to support RSVP-TE P2MP LSPs and IP new Interface ID TLVs are introduced to support RSVP-TE P2MP LSPs, IP
Multicast Tunnels. The TLV value acts as the tunnel identifier. Multicast Tunnels and context labels. The TLV value acts as the
tunnel identifier.
1. RSVP-TE P2MP LSP TLV. Type = TBD. Value of the TLV is the RSVP-TE 1. RSVP-TE P2MP LSP TLV. Type = TBD. Value of the TLV is the RSVP-TE
P2MP Session Object and optionally the P2MP Sender Template Object P2MP Session Object and optionally the P2MP Sender Template Object
[RSVP-TE-P2MP]. The TLV value identifies the RSVP-TE P2MP LSP. It [RSVP-TE-P2MP]. The TLV value identifies the RSVP-TE P2MP LSP. It
allows Ru to tunnel an "inner" LDP P2MP LSP, the label for which is allows Ru to tunnel an "inner" LDP P2MP LSP, the label for which is
upstream assigned, over an "outer" RSVP-TE P2MP LSP that has leaves upstream assigned, over an "outer" RSVP-TE P2MP LSP that has leaves
<Rd1...Rdn>. The P2MP LSP IF_ID TLV allows Ru to signal to <Rd1...Rdn>. The P2MP LSP IF_ID TLV allows Ru to signal to
<Rd1...Rdn> the binding of the inner LDP P2MP LSP to the outer RSVP- <Rd1...Rdn> the binding of the inner LDP P2MP LSP to the outer RSVP-
TE P2MP LSP. The control plane signaling between Ru and <Rd1...Rdn> TE P2MP LSP. The control plane signaling between Ru and <Rd1...Rdn>
for the inner P2MP LSP uses targeted LDP signaling messages for the inner P2MP LSP uses targeted LDP signaling messages
2. IP Multicast Tunnel TLV. Type = TBD. In this case the TLV value is 2. IP Multicast Tunnel TLV. Type = TBD. In this case the TLV value is
a <Source Address, Multicast Group Address> tuple. a <Source Address, Multicast Group Address> tuple. Source Address is
the IP address of the root of the tunnel i.e. Ru, and Multicast Group
Address is the Multicast Group Address used by the tunnel.
3. MPLS Context Label TLV. Type = TBD. In this case the TLV value is
a <Source Address, MPLS Context Label> tuple. The Source Address
belongs to Ru and the MPLS Context Label is an upstream assigned
label, assigned by Ru. This allows Ru to tunnel an "inner" LDP P2MP
LSP, the label of which is upstream assigned, over an "outer" one-hop
MPLS LSP, where the outer one-hop LSP has the following property:
+ The label pushed by Ru for the outer MPLS LSP is an upstream
assigned context label, assigned by Ru. When <Rd1...Rdn> perform
a MPLS label lookup on this label a combination of this label and
the incoming interface MUST be sufficient for <Rd1...Rdn> to
uniquely determine Ru's context specific label space to lookup
the next label on the stack in. <Rd1...Rdn> MUST receive the data
sent by Ru with the context specific label assigned by Ru being
the top label on the label stack.
Currently the usage of the context label TLV is limited only to LDP
P2MP LSPs on a LAN as specified in the next section. The context
label TLV MUST NOT be used for any other purposes.
6. LDP Point-to-Multipoint LSPs on a LAN 6. LDP Point-to-Multipoint LSPs on a LAN
This section describes one application of upstream label assignment This section describes one application of upstream label assignment
using LDP. Further applications are to be described in separate docu- using LDP. Further applications are to be described in separate
ments. documents.
[LDP-P2MP1, LDP-P2MP2] describe how to setup P2MP LSPs using LDP. On [MLDP] describe how to setup P2MP LSPs using LDP. On a LAN the
a LAN the solution relies on "ingress replication". A LSR on a LAN, solution relies on "ingress replication". A LSR on a LAN, that is a
that is a branch LSR for a P2MP LSP, (say Ru) sends a separate copy branch LSR for a P2MP LSP, (say Ru) sends a separate copy of a packet
of a packet that it receives on the P2MP LSP to each of the down- that it receives on the P2MP LSP to each of the downstream LSRs on
stream LSRs on the LAN (say <Rd1...Rdn> that are adjacent to it in the LAN (say <Rd1...Rdn> that are adjacent to it in the P2MP LSP.
the P2MP LSP.
It is desirable for Ru to send a single copy of the packet for the It is desirable for Ru to send a single copy of the packet for the
LDP P2MP LSP on the LAN, when there are multiple downstream routers LDP P2MP LSP on the LAN, when there are multiple downstream routers
on the LAN that are adjacent to Ru in that LDP P2MP LSP. This on the LAN that are adjacent to Ru in that LDP P2MP LSP. This
requires that each of <Rd1...Rdn> must be able to associate the label requires that each of <Rd1...Rdn> must be able to associate the label
L, used by Ru to transmit packets for the P2MP LSP on the LAN, with L, used by Ru to transmit packets for the P2MP LSP on the LAN, with
that P2MP LSP. It is possible to achieve this using LDP upstream- that P2MP LSP. It is possible to achieve this using LDP upstream-
assigned labels with the following procedures. assigned labels with the following procedures.
Consider a LSR Rd that receives the LDP P2MP FEC [LDP-P2MP1, LDP- Consider a LSR Rd that receives the LDP P2MP FEC [MLDP] from its
P2MP2] from its downstream LDP peer. Further the upstream interface downstream LDP peer. Further the upstream interface to reach LSR Ru
to reach LSR Ru which is the next-hop to the P2MP LSP root address, which is the next-hop to the P2MP LSP root address, Pr, in the LDP
Pr, in the LDP P2MP FEC, is a LAN interface. Further Rd and Ru sup- P2MP FEC, is a LAN interface, Li. Further Rd and Ru support upstream-
port upstream-assigned labels. In this case Rd instead of sending a assigned labels. In this case Rd instead of sending a Label Mapping
Label Mapping message as described in [LDP-P2MP1, LDP-P2MP2] sends a message as described in [MLDP] sends a Label Request message to Ru.
Label Request message to Ru. This Label Request message MUST contain This Label Request message MUST contain an Upstream Assigned Label
an Upstream Assigned Label Request TLV. Ru on receiving this message Request TLV.
sends back a Label Mapping message to Rd with an upstream-assigned
label. Processing of the Label Request and Label Mapping messages for Ru on receiving this message sends back a Label Mapping message to Rd
LDP upstream-assigned labels is as described in section 4.2. If Ru with an upstream-assigned label. This message also contains a MPLS
receives a Label Request for an upstream assigned label for the same Context Label TLV, as described in the previous section, with the
P2MP FEC from multiple downstream LSRs on the LAN, <Rd1...Rdn>, it value of the MPLS label set to a value assigned by Ru on inteface Li
MUST send the same upstream-assigned label to each of <Rd1...Rdn>. Ru as specified in [MPLS-UPSTREAM]. Processing of the Label Request and
transmits the MPLS packet with an upstream-assigned label on the LAN Label Mapping messages for LDP upstream-assigned labels is as
using the procedures defined in [MPLS-UPSTREAM] and [MPLS-MCAST- described in section 4.2. If Ru receives a Label Request for an
ENCAPS]. upstream assigned label for the same P2MP FEC from multiple
downstream LSRs on the LAN, <Rd1...Rdn>, it MUST send the same
upstream-assigned label to each of <Rd1...Rdn>.
Ru transmits the MPLS packet using the procedures defined in [MPLS-
UPSTREAM] and [MPLS-MCAST-ENCAPS]. The MPLS packet transmitted by Ru
contains as the top label the context label assigned by Ru on the LAN
interface, Li. The bottom label is the upstream label assigned by Ru
to the LDP P2MP LSP. The top label is looked up in the context of the
LAN interface, Li, [MPLS-UPSTREAM] by a downstream LSR on the LAN.
This lookup enables the downstream LSR to determine the context
specific label space to lookup the inner label in.
Note that <Rd1...Rdn> may have more than one equal cost next-hop on Note that <Rd1...Rdn> may have more than one equal cost next-hop on
the LAN to reach Pr. In this case they MAY be configured to send the the LAN to reach Pr. It MAY be desirable for all of them to send the
upstream assigned label request to the next-hop LSR with the lowest label request to the same upstream LSR and they MAY select one
Router ID, if it is desirable for all of them to send the label upstream LSR using the following procedure:
request to the same upstream LSR. It is also to be noted that these
procedures can still be used by Rd and Ru if other LSRs on the LAN do 1. The candidate upstream LSRs are numbered from lower to higher IP
not support upstream label assignment. Ingress replication and down- address
stream label assignment will continue to be used for LSRs that do not
support upstream label assignment. 2. The following hash is performed: H = (Sum Opaque value) modulo N,
where N is the number of candidate upstream LSRs. Opaque value is
defined in [MLDP] and comprises the P2MP LSP identifier.
3. The selected upstream LSR U is the LSR that has the number H.
This allows for load balancing of a set of LSPs among a set of
candidate upstream LSRs, while ensuring that on a LAN interface a
single upstream LSR is selected. It is also to be noted that the
procedures in this section can still be used by Rd and Ru if other
LSRs on the LAN do not support upstream label assignment. Ingress
replication and downstream label assignment will continue to be used
for LSRs that do not support upstream label assignment.
7. Acknowledgements 7. Acknowledgements
Thanks to Yakov Rekhter for his contribution. Thanks to Ina Minei and Thanks to Yakov Rekhter for his contribution. Thanks to Ina Minei and
Thomas Morin for their comments. Thomas Morin for their comments. The hashing algorithm used on LAN
interfaces is taken from [MLDP].
8. References 8. References
8.1. Normative References 8.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.
[MPLS-UPSTREAM] R. Aggarwal, Y. Rekhter, E. Rosen, "MPLS Upstream [MPLS-UPSTREAM] R. Aggarwal, Y. Rekhter, E. Rosen, "MPLS Upstream
Label Assignment and Context Specific Label Space", draft-ietf-mpls- Label Assignment and Context Specific Label Space", draft-ietf-mpls-
upstream-label-00.txt upstream-label-02.txt
[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-00.txt draft-ietf-mpls-codepoint-01.txt
[RFC2119] "Key words for use in RFCs to Indicate Requirement Lev- [RFC2119] "Key words for use in RFCs to Indicate Requirement
[RFC3472] Ashwood-Smith, P. and L. Berger, Editors, " Generalized [RFC3472] Ashwood-Smith, P. and L. Berger, Editors, " Generalized
Multi-Protocol Label Switching (GMPLS) Signaling - Constraint-based Multi-Protocol Label Switching (GMPLS) Signaling - Constraint-based
Routed Label Distribution Protocol (CR-LDP) Extensions", RFC 3472, Routed Label Distribution Protocol (CR-LDP) Extensions", RFC 3472,
January 2003. January 2003.
[RFC3471] Berger, L. Editor, "Generalized Multi-Protocol Label [RFC3471] Berger, L. Editor, "Generalized Multi-Protocol Label
Switching (GMPLS) Signaling Functional Description", RFC 3471 January Switching (GMPLS) Signaling Functional Description", RFC 3471 January
2003. 2003.
[RFC3036] L. Andersson, et. al., "LDP Specification", January 2001. [RFC3036] L. Andersson, et. al., "LDP Specification", January 2001.
8.2. Informative References 8.2. Informative References
[MVPN] E. Rosen, R. Aggarwal [Editors], "Multicast in BGP/MPLS VPNs" [MVPN] E. Rosen, R. Aggarwal [Editors], "Multicast in BGP/MPLS VPNs",
draft-ietf-l3vpn-2547bis-mcast-02.txt
[RSVP-TE-P2MP] R. Aggarwal, D. Papadimitriou, S. Yasukawa [Editors], [RSVP-TE-P2MP] R. Aggarwal, D. Papadimitriou, S. Yasukawa [Editors],
"Extensions to RSVP-TE for Point to Multipoint TE LSPs" "Extensions to RSVP-TE for Point to Multipoint TE LSPs", draft-ietf-
mpls-rsvp-te-p2mp-07.txt
[LDP-P2MP1] I. Minei et. al, "Label Distribution Protocol Extensions [MLDP] I. Minei et. al, "Label Distribution Protocol Extensions for
for Point-to-Multipoint Label Switched Paths", draft-minei-mpls-ldp- Point-to-Multipoint Label Switched Paths", draft-etf-mpls-ldp-
p2mp-00.txt p2mp-02.txt
[LDP-P2MP2] I. Wijnands et. al., "Multicast Extensions for LDP", [LDP-CAP] B. Thomas, et. al., "LDP Capabilities", draft-thomas-mpls-
draft-wijnands-mpls-ldp-mcast-ext-00.txt ldp-capabilities-02.txt
9. Author Information 9. 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
Jean-Louis Le Roux Jean-Louis Le Roux
France Telecom France Telecom
2, avenue Pierre-Marzin 2, avenue Pierre-Marzin
22307 Lannion Cedex 22307 Lannion Cedex
France France
E-mail: jeanlouis.leroux@francetelecom.com E-mail: jeanlouis.leroux@orange-ftgroup.com
10. Intellectual Property Statement 10. 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.
Copies of IPR disclosures made to the IETF Secretariat and any assur- Copies of IPR disclosures made to the IETF Secretariat and any
ances of licenses to be made available, or the result of an attempt assurances of licenses to be made available, or the result of an
made to obtain a general license or permission for the use of such attempt made to obtain a general license or permission for the use of
proprietary rights by implementers or users of this specification can such proprietary rights by implementers or users of this
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.
11. Full Copyright Statement 11. Full Copyright Statement
Copyright (C) The Internet Society (2006). This document is subject Copyright (C) The IETF Trust (2007). This document is subject to the
to the rights, licenses and restrictions contained in BCP 78, and rights, licenses and restrictions contained in BCP 78, and except as
except as set forth therein, the authors retain all their rights. 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 AND THE INTERNET OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFOR- OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
MATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
 End of changes. 36 change blocks. 
119 lines changed or deleted 154 lines changed or added

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