draft-ietf-mpls-rsvp-upstream-03.txt   draft-ietf-mpls-rsvp-upstream-04.txt 
Network Working Group R. Aggarwal Network Working Group R. Aggarwal
Internet Draft Juniper Networks Internet Draft Juniper Networks
Expiration Date: January 2009 Expiration Date: January 2010
J. L. Le Roux J. L. Le Roux
France Telecom France Telecom
July 8, 2008 July 12, 2009
MPLS Upstream Label Assignment for RSVP-TE MPLS Upstream Label Assignment for RSVP-TE
draft-ietf-mpls-rsvp-upstream-03.txt draft-ietf-mpls-rsvp-upstream-04.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any This Internet-Draft is submitted to IETF in full conformance with the
applicable patent or other IPR claims of which he or she is aware provisions of BCP 78 and BCP 79.
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 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 other
other groups may also distribute working documents as Internet- groups may also distribute working documents as Internet-Drafts.
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
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.
Copyright and License Notice
Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other
than English.
Abstract Abstract
This document describes procedures for distributing upstream-assigned This document describes procedures for distributing upstream-assigned
labels for Resource Reservation Protocol - Traffic Engineering (RSVP- labels for Resource Reservation Protocol - Traffic Engineering (RSVP-
TE). It also describes how these procedures can be used for avoiding TE). It also describes how these procedures can be used for avoiding
branch LSR traffic replication on a LAN for RSVP-TE point-to- branch LSR traffic replication on a LAN for RSVP-TE point-to-
multipoint (P2MP)LSPs. multipoint (P2MP)LSPs.
Table of Contents Table of Contents
1 Specification of requirements ......................... 2 1 Specification of requirements ......................... 3
2 Introduction .......................................... 2 2 Introduction .......................................... 3
3 RSVP-TE Upstream Label Assignment Capability .......... 3 3 RSVP-TE Upstream Label Assignment Capability .......... 3
4 Distributing Upstream-Assigned Labels in RSVP-TE ...... 4 4 Distributing Upstream-Assigned Labels in RSVP-TE ...... 4
4.1 Procedures ............................................ 4 4.1 Procedures ............................................ 5
5 RSVP-TE Tunnel Identifier Exchange .................... 5 5 RSVP-TE Tunnel Identifier Exchange .................... 5
6 RSVP-TE Point-to-Multipoint LSPs on a LAN ............. 6 6 RSVP-TE Point-to-Multipoint LSPs on a LAN ............. 7
7 Acknowledgements ...................................... 7 7 IANA Considerations ................................... 8
8 References ............................................ 7 8 Acknowledgements ...................................... 8
8.1 Normative References .................................. 7 9 References ............................................ 9
8.2 Informative References ................................ 8 9.1 Normative References .................................. 9
9 Author's Address ...................................... 8 9.2 Informative References ................................ 9
10 Intellectual Property Statement ....................... 8 10 Author's Address ...................................... 10
11 Full Copyright Statement .............................. 9
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
labels [MPLS-UPSTREAM] for Resource Reservation Protocol with Traffic labels [RFC5331] for Resource Reservation Protocol with Traffic
Engineering (RSVP-TE). These procedures follow the architecture for Engineering (RSVP-TE). These procedures follow the architecture for
MPLS Upstream Label Assignment described in [MPLS-UPSTREAM]. MPLS Upstream Label Assignment described in [RFC5331].
This document describes extensions to RSVP-TE that a LSR can use to This document describes extensions to RSVP-TE 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 RSVP-TE to distribute This document also describes extensions to RSVP-TE to distribute
upstream-assigned labels. upstream-assigned labels.
The usage of MPLS upstream label assignment using RSVP-TE for The usage of MPLS upstream label assignment using RSVP-TE for
avoiding branch LSR [RSVP-P2MP] traffic replication on a LAN for avoiding branch LSR [RSVP-P2MP] traffic replication on a LAN for
RSVP-TE P2MP TE LSPs [RFC4875] is also described. RSVP-TE P2MP TE LSPs [RFC4875] is also described.
3. RSVP-TE Upstream Label Assignment Capability 3. RSVP-TE Upstream Label Assignment Capability
According to [MPLS-UPSTREAM], upstream-assigned label bindings MUST According to [RFC5331], upstream-assigned label bindings MUST NOT be
NOT be used unless it is known that a downstream LSR supports them. used unless it is known that a downstream LSR supports them. This
This implies that there MUST be a mechanism to enable a LSR to implies that there MUST be a mechanism to enable a LSR to advertise
advertise to its RSVP-TE neighbor LSR(s) its support of upstream- to its RSVP-TE neighbor LSR(s) its support of upstream-assigned
assigned labels. labels.
[RSVP-RESTART] defines a CAPABILITY object to be carried within Hello [RFC5063] defines a CAPABILITY object to be carried within Hello
messages, and used to indicate the set of capabilities supported by a messages, and used to indicate the set of capabilities supported by a
node. Currently one flag is defined, the R flag indicating the node. This object provides the ability to encode a set of capability
support for RecoveryPath Srefresh. This document defines a new flag, flags. This document defines a new flag, the U flag, to signal a
the U flag, to signal a LSR's support of upstream label assignment to LSR's support of upstream label assignment to its RSVP-TE neighbors.
its RSVP-TE neighbors.
The format of a Capability object is: The format of a Capability object is:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Class-Num(TBA)| C-Type (1) | | Length | Class-Num(TBA)| C-Type (1) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |U|R| | Reserved |U|T|R|S|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Recovery Path Srefresh Capable (R): 1 bit, defined in [RSVP-RESTART]. T, R and S flags are defined in [RFC5063].
Upstream Label Assignement Capable (U): 1 bit When set this means Upstream Label Assignement Capable (U): 1 bit When set this means
that the LSR is capable of both distributing upstream-assigned label that the LSR is capable of both distributing upstream-assigned label
bindings and receiving upstream-assigned label bindings bindings and receiving upstream-assigned label bindings
Reserved bits MUST be set to zero on transmission and MUST be ignored Reserved bits MUST be set to zero on transmission and MUST be ignored
on receipt. on receipt.
The usage of RSVP-TE Hello messages for exchanging upstream label The usage of RSVP-TE Hello messages for exchanging upstream label
assignment capability implies that a LSR MAY exchange RSVP-TE Hellos assignment capability implies that a LSR MAY exchange RSVP-TE Hellos
skipping to change at page 4, line 40 skipping to change at page 5, line 19
A RSVP-TE LSR MUST NOT distribute the UPSTREAM_ASSIGNED_LABEL Object A RSVP-TE LSR MUST NOT distribute the UPSTREAM_ASSIGNED_LABEL Object
to a downstream LSR if the downstream LSR had not previously to a downstream LSR if the downstream LSR had not previously
advertised the CAPABILITY object with the U bit set in its RSVP-TE advertised the CAPABILITY object with the U bit set in its RSVP-TE
Hello messages. Hello messages.
If a downstream RSVP-TE LSR receives a Path message that carries an If a downstream RSVP-TE LSR receives a Path message that carries an
UPSTREAM_ASSIGNED_LABEL Object and the LSR does not support the UPSTREAM_ASSIGNED_LABEL Object and the LSR does not support the
object C-Num/C-Type it will return an "Unknown Object C-Num/C-Type" object C-Num/C-Type it will return an "Unknown Object C-Num/C-Type"
error. If the LSR does support the object, but is unable to process error. If the LSR does support the object, but is unable to process
the upstream-assigned label as described in [MPLS-UPSTREAM] it SHOULD the upstream-assigned label as described in [RFC5331] it SHOULD send
send a PathErr with the error code "Routing problem" and the error a PathErr with the error code "Routing problem" and the error value
value "MPLS Upstream Assigned Label Processing Failure". If the LSR "MPLS Upstream Assigned Label Processing Failure". If the LSR
successfully processes the Path message and the upstream-assigned successfully processes the Path message and the upstream-assigned
label it MUST send a Resv message upstream as per [RFC3209] but it label it MUST send a Resv message upstream as per [RFC3209] but it
MUST NOT include the LABEL object with a downstream assigned label in MUST NOT include the LABEL object with a downstream assigned label in
the Resv Message. This is because as described in [MPLS-UPSTREAM] two the Resv Message. This is because as described in [RFC5331] two LSRs
LSRs Ru and Rd for a LSP that is bound to FEC F, MUST use either Ru and Rd for a LSP that is bound to FEC F, MUST use either
downstream-assigned label distribution or upstream-assigned label downstream-assigned label distribution or upstream-assigned label
distribution,for FEC F, but NOT both, for packets that are to be distribution,for FEC F, but NOT both, for packets that are to be
transmitted on the LSP from Ru to Rd. transmitted on the LSP from Ru to Rd.
5. RSVP-TE Tunnel Identifier Exchange 5. RSVP-TE Tunnel Identifier Exchange
As described in [MPLS-UPSTREAM] an upstream LSR Ru MAY transmit a As described in [RFC5331] an upstream LSR Ru MAY transmit a MPLS
MPLS packet, the top label of which (L) is upstream-assigned, to a 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 RSVP-TE is used for upstream label assignment, the IF_ID When RSVP-TE is used for upstream label assignment, the IF_ID
RSVP_HOP object is used for signaling the Tunnel Identifier. If Ru RSVP_HOP object is used for signaling the Tunnel Identifier. If Ru
uses an IP or MPLS tunnel to transmit MPLS packets with upstream uses an IP or MPLS tunnel to transmit MPLS packets with upstream
assigned labels to Rd, Ru MUST include the IF_ID RSVP_HOP object assigned labels to Rd, Ru MUST include the IF_ID RSVP_HOP object
[RFC3473] in Path messages along with the UPSTREAM_ASSIGNED_LABEL [RFC3473] in Path messages along with the UPSTREAM_ASSIGNED_LABEL
Object. Object.
Three new TLVs are introduced in the IF_ID RSVP_HOP object [RFC3471] Four new TLVs are introduced in the IF_ID RSVP_HOP object [RFC3471]
to support RSVP-TE P2MP LSPs, IP Multicast Tunnels and context to support RSVP-TE P2MP LSPs, LDP P2MP LSPs, IP Multicast Tunnels and
labels. The TLV value acts as the tunnel identifier. 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
[RFC4875]. The TLV value identifies the RSVP-TE P2MP LSP. This [RFC4875]. The TLV value identifies the RSVP-TE P2MP LSP. This
mechanism extends RSVP-TE P2P Hierarchy [LSP-HIER] to RSVP-TE P2MP mechanism extends RSVP-TE P2P Hierarchy [LSP-HIER] to RSVP-TE P2MP
Hierarchy. It allows Ru to tunnel an "inner" P2MP LSP, the label for Hierarchy. It allows Ru to tunnel an "inner" RSVP-TE P2MP LSP, the
which is upstream assigned, over an "outer" P2MP LSP that has leaves label for which is 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 binding of the inner P2MP LSP to the outer
P2MP LSP. The control plane signaling between Ru and <Rd1...Rdn> for
the inner P2MP LSP uses directed RSVP-TE signaling messages as in
[LSP-HIER].
2. LDP P2MP LSP TLV. Type = TBD. Value of the TLV is the LDP P2MP FEC
as defined in [MLDP]. The TLV value identifies the LDP P2MP LSP. It
allows Ru to tunnel an "inner" RSVP-TE P2MP LSP, the label for which
is upstream assigned, over an "outer" LDP 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 P2MP LSP to the outer P2MP LSP. <Rd1...Rdn> the binding of the inner LDP P2MP LSP to the outer LDP-
The control plane signaling between Ru and <Rd1...Rdn> for the inner P2MP LSP. The control plane signaling between Ru and <Rd1...Rdn> for
P2MP LSP uses directed RSVP-TE signaling messages as in [LSP-HIER]. the inner P2MP LSP uses directed RSVP-TE signaling messages as in
[LSP-HIER].
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. Source Address is 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 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. Address is the Multicast Group Address used by the tunnel.
3. MPLS Context Label TLV. Type = TBD. In this case the TLV value is 3. MPLS Context Label TLV. Type = TBD. In this case the TLV value is
a <Source Address, MPLS Context Label> tuple. The Source Address a <Source Address, MPLS Context Label> tuple. The Source Address
belongs to Ru and the MPLS Context Label is an upstream assigned belongs to Ru and the MPLS Context Label is an upstream assigned
label, assigned by Ru. This allows Ru to tunnel an "inner" RSVP-TE label, assigned by Ru. This allows Ru to tunnel an "inner" RSVP-TE
skipping to change at page 6, line 18 skipping to change at page 6, line 52
the incoming interface MUST be sufficient for <Rd1...Rdn> to the incoming interface MUST be sufficient for <Rd1...Rdn> to
uniquely determine Ru's context specific label space to lookup uniquely determine Ru's context specific label space to lookup
the next label on the stack in. <Rd1...Rdn> MUST receive the data 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 sent by Ru with the context specific label assigned by Ru being
the top label on the label stack. the top label on the label stack.
Currently the usage of the context label TLV is limited only to RSVP- Currently the usage of the context label TLV is limited only to RSVP-
TE P2MP LSPs on a LAN as specified in the next section. The context TE P2MP LSPs on a LAN as specified in the next section. The context
label TLV MUST NOT be used for any other purposes. label TLV MUST NOT be used for any other purposes.
Note that when the outer P2MP LSP is signaled with RSVP-TE or MLDP
the above procedures assume that Ru has a priori knowledge of all the
<Rd1, ... Rdn>. In the scenario where the outer P2MP LSP is signaled
using RSVP-TE, Ru can obtain this information from RSVP-TE. However,
in the scenario where the outer P2MP LSP is signaled using MLDP, MLDP
does not provide this information to Ru. In this scenario the
procedures by which Ru could acquire this information are outside the
scope of this document.
6. RSVP-TE Point-to-Multipoint LSPs on a LAN 6. RSVP-TE 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 RSVP-TE. Further applications are to be described in separate using RSVP-TE. Further applications are to be described in separate
documents. documents.
[RFC4875] describes how to setup RSVP-TE P2MP LSPs. On a LAN the [RFC4875] describes how to setup RSVP-TE P2MP LSPs. On a LAN the
solution described in [RFC4875] relies on "ingress replication". A solution described in [RFC4875] relies on "ingress replication". A
LSR on a LAN (say Il), that is a branch LSR for a P2MP LSP, (say Ru) LSR on a LAN (say Il), that is a branch LSR for a P2MP LSP, (say Ru)
sends a separate copy of a packet that it receives on the P2MP LSP to sends a separate copy of a packet that it receives on the P2MP LSP to
skipping to change at page 6, line 46 skipping to change at page 7, line 40
transmit packets for the P2MP LSP on the LAN, with that P2MP LSP. It transmit packets for the P2MP LSP on the LAN, with that P2MP LSP. It
is possible to achieve this using RSVP-TE upstream-assigned labels is possible to achieve this using RSVP-TE upstream-assigned labels
with the following procedures. Assume that Ru and <Rd1...Rdn> support with the following procedures. Assume that Ru and <Rd1...Rdn> support
upstream label assignment. upstream label assignment.
Ru sends a Path message for the P2MP LSP to each of <Rd1...Rdn> that Ru sends a Path message for the P2MP LSP to each of <Rd1...Rdn> that
is adjacent on the P2MP LSP, with the same UPSTREAM_ASSIGNED_LABEL is adjacent on the P2MP LSP, with the same UPSTREAM_ASSIGNED_LABEL
object. This object carries an upstream assigned label, L. This object. This object carries an upstream assigned label, L. This
message also carries a MPLS Context Label TLV, as described in the message also carries a MPLS Context Label TLV, as described in the
previous section, with the value of the MPLS label set to a value previous section, with the value of the MPLS label set to a value
assigned by Ru on inteface I1 as specified in [MPLS-UPSTREAM]. assigned by Ru on inteface I1 as specified in [RFC5331]. <Rd1...Rdn>
<Rd1...Rdn> "reserve" the upstream assigned label in the separate "reserve" the upstream assigned label in the separate Upstream
Upstream Neighbor Label Space that they maintain for Ru [MPLS- Neighbor Label Space that they maintain for Ru [RFC5331].
UPSTREAM].
Ru can then transmit a single packet for the P2MP LSP to <Rd1..Rdn> Ru can then transmit a single packet for the P2MP LSP to <Rd1..Rdn>
with a top label L using procedures defined in [MPLS-UPSTREAM] and with a top label L using procedures defined in [RFC5331] and
[MPLS-MCAST-ENCAPS]. The MPLS packet transmitted by Ru contains as [RFC5332]. The MPLS packet transmitted by Ru contains as the top
the top label the context label assigned by Ru on the LAN interface, label the context label assigned by Ru on the LAN interface, I1. The
I1. The bottom label is the upstream label assigned by Ru to the bottom label is the upstream label assigned by Ru to the RSVP-TE P2MP
RSVP-TE P2MP LSP. The top label is looked up in the context of the LSP. The top label is looked up in the context of the LAN interface,
LAN interface, I1, [MPLS-UPSTREAM] by a downstream LSR on the LAN. I1, [RFC5331] by a downstream LSR on the LAN. This lookup enables the
This lookup enables the downstream LSR to determine the context downstream LSR to determine the context specific label space to
specific label space to lookup the inner label in. lookup the inner label in.
If a subset of <Rd1...Rdn> do not support upstream label assignment If a subset of <Rd1...Rdn> do not support upstream label assignment
these procedures can still be used between Ru and the remaining these procedures can still be used between Ru and the remaining
subset of <Rd1...Rdn>. Ingress replication and downstream label subset of <Rd1...Rdn>. Ingress replication and downstream label
assignment will continue to be used for LSRs that do not support assignment will continue to be used for LSRs that do not support
upstream label assignment. upstream label assignment.
7. Acknowledgements 7. IANA Considerations
This document defines a new U flag in the CAPABILITY object defined
by [RFC5063]. IANA is requested to assign a new bit to this flag from
the 32 bit flags field of the CAPABILITY object.
This document defines a new RSVP-TE object, the
UPSTREAM_ASSIGNED_LABEL object. The Class-Num for this object comes
from the 0bbbbbbb space and IANA is requested to assign this Class-
Num.
This document defines four new TLVs in the IF_ID RSVP_HOP object
[RFC3471]:
- RSVP-TE P2MP LSP TLV
- LDP P2MP LSP TLV
- IP Multicast Tunnel TLV
- MPLS Context Label TLV
IANA is requested to assign the type values of these TLVs.
8. 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.
8. References 9. References
8.1. Normative References 9.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 [RFC5331] R. Aggarwal, Y. Rekhter, E. Rosen, "MPLS Upstream Label
Label Assignment and Context Specific Label Space", draft-ietf-mpls- Assignment and Context Specific Label Space", draft-ietf-mpls-
upstream-label-05.txt upstream-label-05.txt
[MPLS-MCAST-ENCAPS] T. Eckert, E. Rosen, R. Aggarwal, Y. Rekhter, [RFC5332] T. Eckert, E. Rosen, R. Aggarwal, Y. Rekhter, draft-ietf-
draft-ietf-mpls-codepoint-08.txt mpls-codepoint-08.txt
[RFC3209] Awduche et. al." "RSVP-TE: Extensions to RSVP for LSP [RFC3209] Awduche et. al." "RSVP-TE: Extensions to RSVP for LSP
Tunnels", RFC 3209, December 2001. Tunnels", RFC 3209, December 2001.
[RFC2119] "Key words for use in RFCs to Indicate Requirement [RFC2119] "Key words for use in RFCs to Indicate Requirement
[RFC3473] Berger, L., Editor, "Generalized Multi-Protocol Label [RFC3473] Berger, L., Editor, "Generalized Multi-Protocol Label
Switching (GMPLS) Signaling - Resource ReserVation Protocol-Traffic Switching (GMPLS) Signaling - Resource ReserVation Protocol-Traffic
Engineering (RSVP-TE) Extensions", RFC 3473, January 2003. Engineering (RSVP-TE) Extensions", RFC 3473, 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.
[RSVP-RESTART] A. Satyanarayana et. al., "Extensions to GMPLS RSVP [RFC5063] A. Satyanarayana et. al., "Extensions to GMPLS Resource
Graceful Restart", draft-ietf-ccamp-rsvp-restart-ext-02.txt Reservation Protocol (RSVP) Graceful Restart", RFC5063
8.2. Informative References 9.2. Informative References
[MVPN] E. Rosen, R. Aggarwal [Editors], "Multicast in BGP/MPLS VPNs", [MVPN] E. Rosen, R. Aggarwal [Editors], "Multicast in BGP/MPLS VPNs",
draft-ietf-l3vpn-2547bis-mcast-06.txt draft-ietf-l3vpn-2547bis-mcast-06.txt
[RFC4875] R. Aggarwal, D. Papadimitriou, S. Yasukawa [Editors], [RFC4875] R. Aggarwal, D. Papadimitriou, S. Yasukawa [Editors],
"Extensions to RSVP-TE for Point to Multipoint TE LSPs", RFC 4875 "Extensions to RSVP-TE for Point to Multipoint TE LSPs", RFC 4875
9. Author's Address 10. Author's Address
Rahul Aggarwal Rahul Aggarwal
Juniper Networks Juniper Networks
1194 North Mathilda Ave. 1194 North Mathilda Ave.
Sunnyvale, CA 94089 Sunnyvale, CA 94089
Phone: +1-408-936-2720 Phone: +1-408-936-2720
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@orange-ftgroup.com E-mail: jeanlouis.leroux@orange-ftgroup.com
10. Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
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
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
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
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf-
ipr@ietf.org.
11. 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.
 End of changes. 34 change blocks. 
73 lines changed or deleted 134 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/