draft-ietf-mpls-rsvp-upstream-02.txt   draft-ietf-mpls-rsvp-upstream-03.txt 
Network Working Group R. Aggarwal Network Working Group R. Aggarwal
Internet Draft Juniper Networks Internet Draft Juniper Networks
Expiration Date: May 20, 2008 Expiration Date: January 2009
J. L. Le Roux J. L. Le Roux
France Telecom France Telecom
November 17, 2007 July 8, 2008
MPLS Upstream Label Assignment for RSVP-TE MPLS Upstream Label Assignment for RSVP-TE
draft-ietf-mpls-rsvp-upstream-02.txt draft-ietf-mpls-rsvp-upstream-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 2, line 18 skipping to change at page 2, line 18
2 Introduction .......................................... 2 2 Introduction .......................................... 2
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 ............................................ 4
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 ............. 6
7 Acknowledgements ...................................... 7 7 Acknowledgements ...................................... 7
8 References ............................................ 7 8 References ............................................ 7
8.1 Normative References .................................. 7 8.1 Normative References .................................. 7
8.2 Informative References ................................ 8 8.2 Informative References ................................ 8
9 Author Information .................................... 8 9 Author's Address ...................................... 8
10 Intellectual Property Statement ....................... 8 10 Intellectual Property Statement ....................... 8
11 Full Copyright Statement .............................. 9 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
skipping to change at page 3, line 5 skipping to change at page 3, line 5
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 [RSVP-TE-P2MP] 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 [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 This implies that there MUST be a mechanism to enable a LSR to
advertise to its RSVP-TE neighbor LSR(s) its support of upstream- advertise to its RSVP-TE neighbor LSR(s) its support of upstream-
assigned labels. assigned labels.
[RSVP-RESTART] defines a CAPABILITY object to be carried within Hello [RSVP-RESTART] defines a CAPABILITY object to be carried within Hello
skipping to change at page 5, line 29 skipping to change at page 5, line 29
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] Three 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, IP Multicast Tunnels and context
labels. The TLV value acts as the tunnel identifier. 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. 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" P2MP LSP, the label for
which is upstream assigned, over an "outer" P2MP LSP that has leaves which is upstream assigned, over an "outer" 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 P2MP LSP to the outer P2MP LSP.
The control plane signaling between Ru and <Rd1...Rdn> for the inner The control plane signaling between Ru and <Rd1...Rdn> for the inner
P2MP LSP uses directed RSVP-TE signaling messages as in [LSP-HIER]. 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
skipping to change at page 6, line 24 skipping to change at page 6, line 24
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.
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.
[RSVP-TE-P2MP] 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 [RSVP-TE-P2MP] relies on "ingress replication". solution described in [RFC4875] relies on "ingress replication". A
A LSR on a LAN (say Il), that is a branch LSR for a P2MP LSP, (say LSR on a LAN (say Il), that is a branch LSR for a P2MP LSP, (say Ru)
Ru) sends a separate copy of a packet that it receives on the P2MP sends a separate copy of a packet that it receives on the P2MP LSP to
LSP to each of the downstream LSRs on the LAN (say <Rd1...Rdn> that each of the downstream LSRs on the LAN (say <Rd1...Rdn> that are
are adjacent to it in the P2MP LSP. adjacent to it in the P2MP LSP.
In order to increase efficiency of bandwidth utilization, it is In order to increase efficiency of bandwidth utilization, it is
desirable for Ru to send a single copy of the packet for the P2MP LSP desirable for Ru to send a single copy of the packet for the P2MP LSP
on the LAN, when there are multiple downstream routers on the LAN on the LAN, when there are multiple downstream routers on the LAN
that are adjacent in that P2MP LSP. This requires that each of that are adjacent in that P2MP LSP. This requires that each of
<Rd1...Rdn> must be able to associate the label L, used by Ru to <Rd1...Rdn> must be able to associate the label L, used by Ru to
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.
skipping to change at page 7, line 33 skipping to change at page 7, line 33
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-03.txt upstream-label-05.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-07.txt draft-ietf-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 [RSVP-RESTART] A. Satyanarayana et. al., "Extensions to GMPLS RSVP
Graceful Restart", draft-ietf-ccamp-rsvp-restart-ext-02.txt Graceful Restart", draft-ietf-ccamp-rsvp-restart-ext-02.txt
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 draft-ietf-l3vpn-2547bis-mcast-06.txt
[RSVP-TE-P2MP] 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", draft-ietf- "Extensions to RSVP-TE for Point to Multipoint TE LSPs", RFC 4875
mpls-rsvp-te-p2mp-07.txt
9. Author's Address 9. 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
skipping to change at page 9, line 18 skipping to change at page 9, line 17
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 IETF Trust (2007). This document is subject to the Copyright (C) The IETF Trust (2008). This document is subject to the
rights, licenses and restrictions contained in BCP 78, and except as rights, licenses and restrictions contained in BCP 78, and 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, 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. 12 change blocks. 
19 lines changed or deleted 18 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/