Internet DRAFT - draft-raggarwa-mpls-rsvp-ldp-upstream
draft-raggarwa-mpls-rsvp-ldp-upstream
Network Working Group R. Aggarwal
Internet Draft Juniper Networks
Expiration Date: January 2006
J. L. Le Roux
France Telecom
July 2005
MPLS Upstream Label Assignment for RSVP-TE and LDP
draft-raggarwa-mpls-rsvp-ldp-upstream-00.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Abstract
This document describes procedures for distributing upstream-assigned
labels for Resource Reservation Protocol - Traffic Engineering (RSVP-
TE) and Label Distribution Protocol (LDP). It also describes how
these procedures can be used for avoiding branch LSR traffic
replication on a LAN for RSVP-TE and LDP point-to-multipoint
(P2MP)LSPs.
Raggarwa & LeRoux [Page 1]
Internet Draftdraft-raggarwa-mpls-rsvp-ldp-upstream-00.txt July 2005
Table of Contents
1 Specification of requirements ......................... 2
2 Introduction .......................................... 2
3 Upstream Label Assignment Capability .................. 3
3.1 RSVP-TE Upstream Label Assignment Capability .......... 3
3.2 LDP Upstream Label Assignment Capability .............. 4
4 Distributing Upstream-Assigned Labels ................. 4
4.1 Distributing Upstream-Assigned Labels in RSVP-TE ...... 4
4.1.1 Procedures ............................................ 5
4.2 Distributing Upstream-Assigned Labels in LDP .......... 5
4.2.1 Procedures ............................................ 6
5 Tunnel Identifier Exchange ............................ 7
5.1 RSVP-TE Tunnel Identifier Exchange .................... 7
5.2 LDP Tunnel Identifier Exchange ........................ 8
6 Point-to-Multipoint LSPs on a LAN ..................... 8
6.1 RSVP-TE P2MP LSPs ..................................... 8
6.2 LDP P2MP LSPs ......................................... 9
7 Acknowledgements ...................................... 10
8 References ............................................ 10
8.1 Normative References .................................. 10
8.2 Informative References ................................ 11
9 Author Information .................................... 11
10 Intellectual Property Statement ....................... 11
11 Full Copyright Statement .............................. 12
1. Specification of requirements
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
2. Introduction
This document describes procedures for distributing upstream-assigned
labels [MPLS-UPSTREAM] for Resource Reservation Protocol with Traffic
Engineering (RSVP-TE) and Label Distribution Protocol (LDP). These
procedures follow the architecture for MPLS Upstream Label Assignment
described in [MPLS-UPSTREAM].
This document describes extensions to RSVP-TE and LDP that a LSR can
Raggarwa & LeRoux [Page 2]
Internet Draftdraft-raggarwa-mpls-rsvp-ldp-upstream-00.txt July 2005
use to advertise to its neighboring LSRs whether the LSR supports
upstream label assignment.
This document also describes extensions to RSVP-TE and LDP to dis-
tribute upstream-assigned labels.
The usage of MPLS upstream label assignment using RSVP-TE and LDP for
avoiding branch LSR [RSVP-P2MP] traffic replication on a LAN for
RSVP-TE P2MP TE LSPs [RSVP-TE-P2MP] and LDP P2MP LSPs [LDP-P2MP1,
LDP-P2MP2] is also described.
3. Upstream Label Assignment Capability
According to [MPLS-UPSTREAM], upstream-assigned label bindings MUST
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-
tise to its RSVP-TE or LDP neighbor LSR(s) its support of upstream-
assigned labels.
3.1. RSVP-TE Upstream Label Assignment Capability
[RSVP-RESTART] defines a CAPABILITY object to be carried within Hello
messages, and used to indicate the set of capabilities supported by a
node. Currently one flag is defined, the R flag indicating the sup-
port for RecoveryPath Srefresh. This document defines a new flag, the
U flag, to signal a LSR's support of upstream label assignment to its
RSVP-TE neighbors.
The format of a Capability object is:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Class-Num(TBA)| C-Type (1) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |U|R|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Recovery Path Srefresh Capable (R): 1 bit, defined in [RSVP-RESTART].
Upstream Label Assignement Capable (U): 1 bit When set this means
that the LSR is capable of both distributing upstream-assigned label
bindings and receiving upstream-assigned label bindings
Reserved bits MUST be set to zero on transmission and MUST be ignored
Raggarwa & LeRoux [Page 3]
Internet Draftdraft-raggarwa-mpls-rsvp-ldp-upstream-00.txt July 2005
on receipt.
The usage of RSVP-TE Hello messages for exchanging upstream label
assignment capability implies that a LSR MAY exchange RSVP-TE Hellos
with a neighbor before sending/receiving any other RSVP-TE messages
to/from that neighbor.
3.2. LDP Upstream Label Assignment Capability
A new optional parameter, the Upstream Label Assignment Capability
TLV, is introduced to signal a LSR's support of upstream label
assignment, to its LDP peers. This optional parameter is carried in
LDP Initialization messages.
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| Upstream Lbl Ass Cap (TBD)| Length (= 4) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
If a LSR includes the Upstream Label Assignment Capability TLV in LDP
Initialization Messages it implies that the LSR is capable of both
distributing upstream-assigned label bindings and receiving upstream-
assigned label bindings. Reserved bits MUST be set to zero on trans-
mission and MUST be ignored on receipt.
4. Distributing Upstream-Assigned Labels
4.1. Distributing Upstream-Assigned Labels in RSVP-TE
An optional RSVP-TE object, the UPSTREAM_ASSIGNED_LABEL object is
introduced to signal an upstream-assigned label. The Class-Num for
this object comes from the 0bbbbbbb space and is to be determined by
IANA.
UPSTREAM_ASSIGNED_LABEL C-Num = TBD
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label |
Raggarwa & LeRoux [Page 4]
Internet Draftdraft-raggarwa-mpls-rsvp-ldp-upstream-00.txt July 2005
| .... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The label can be encoded as in [RFC3209] when the C-Type is 1 or as a
Generalized Label [RFC3473] when the C-Type is 2 or 3.
4.1.1. Procedures
A RSVP-TE LSR that assigns Upstream-Assigned Labels, distributes them
to the downstream LSRs by including them in RSVP-TE Path messages.
A RSVP-TE LSR MUST NOT distribute the UPSTREAM_ASSIGNED_LABEL Object
to a downstream LSR if the downstream LSR had not previously adver-
tised the CAPABILITY object with the U bit set in its RSVP-TE Hello
messages.
If a downstream RSVP-TE LSR receives a Path message that carries an
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"
error. If the LSR does support the object, but is unable to process
the upstream-assigned label as described in [MPLS-UPSTREAM] it SHOULD
send a PathErr with the error code "Routing problem" and the error
value "MPLS Upstream Assigned Label Processing Failure". If the LSR
successfully processes the Path message and the upstream-assigned
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
the Resv Message. This is because as described in [MPLS-UPSTREAM] two
LSRs Ru and Rd for a LSP that is bound to FEC F, MUST use either
downstream-assigned label distribution or upstream-assigned label
distribution,for FEC F, but NOT both, for packets that are to be
transmitted on the LSP from Ru to Rd.
4.2. Distributing Upstream-Assigned Labels in LDP
An optional LDP TLV, Upstream-Assigned Label Request TLV, is intro-
duced. This TLV MUST be carried in a Label Request message if an
upstream-assigned label is being requested.
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|0| Upstream Ass Lbl Req (TBD)| Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Raggarwa & LeRoux [Page 5]
Internet Draftdraft-raggarwa-mpls-rsvp-ldp-upstream-00.txt July 2005
An optional LDP TLV, Upstream-Assigned Label TLV is introduced to
signal an upstream-assigned label. Upstream-Assigned Label TLVs are
carried by the messages used to advertise, release and withdraw
upstream assigned label mappings.
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|0| Upstream Ass Label (TBD) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Label
This is a 20-bit label value as specified in [RFC3032] represented as
a 20-bit number in a 4 octet field.
4.2.1. Procedures
Procedures for Label Mapping, Label Request, Label Abort, Label With-
draw and Label Release follow [RFC3036] other than the modifications
pointed out in this section.
A LDP LSR MUST NOT distribute the Upstream Assigned Label TLV to a
neighboring LSR if the neighboring LSR had not previously advertised
the Upstream Label Assignment Capability in its LDP Initialization
messages. A LDP LSR MUST NOT send the Upstream Assigned Label
Request TLV to a neighboring LSR if the neighboring LSR had not pre-
viously advertised the Upstream Label Assignment Capability in its
LDP Initialization messages.
As described in [MPLS-UPSTREAM] the distribution of upstream-assigned
labels is similar to either ordered LSP control or independent LSP
control of the downstream assigned labels.
When the label distributed in a Label Mapping message is an upstream-
assigned label, the Upstream Assigned Label TLV MUST be included in
the Label Mapping message. When a LSR receives a Label Mapping mes-
sage with an Upstream Assigned Label TLV and if it does not recognize
the TLV, it MUST generate a Notification message with a status code
of "Unknown TLV" [RFC3036]. If it does recognize the TLV but is
unable to process the upstream label, it MUST generate a Notification
message with a status code of "No Label Resources". If the Label Map-
ping message was generated in response to a Label Request message,
Raggarwa & LeRoux [Page 6]
Internet Draftdraft-raggarwa-mpls-rsvp-ldp-upstream-00.txt July 2005
the Label Request message MUST contain an Upstream Assigned Label
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
mapping to the neighbor LSR for that FEC unless it withdraws the
upstream-assigned label binding. Similarly if a LSR generates a down-
stream assigned label request to a neighbor LSR, for a given FEC, it
MUST NOT send an upstream label mapping to that LSR for that FEC,
unless it aborts the downstream assigned label request.
The Upstream Assigned Label TLV may be optionally included in Label
Withdraw and Label Release messages that withdraw/release a particu-
lar upstream assigned label binding.
5. Tunnel Identifier Exchange
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
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
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
used by Ru for transmitting MPLS packets with upstream-assigned MPLS
labels.
5.1. RSVP-TE Tunnel Identifier Exchange
When RSVP-TE is used for upstream label assignment, the IF_ID
RSVP_HOP object is used for signaling the Tunnel Identifier. If Ru
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
[RFC3473] in Path messages along with the UPSTREAM_ASSIGNED_LABEL
Object.
Two new TLVs are introduced in the IF_ID RSVP_HOP object [RFC3471] to
support RSVP-TE P2MP LSPs and IP Multicast Tunnels. The TLV value
acts as the tunnel identifier.
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
[RSVP-TE-P2MP]. The TLV value identifies the RSVP-TE P2MP LSP. This
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
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 binding of the inner P2MP LSP to the outer P2MP LSP.
The control plane signaling between Ru and <Rd1...Rdn> for the inner
Raggarwa & LeRoux [Page 7]
Internet Draftdraft-raggarwa-mpls-rsvp-ldp-upstream-00.txt July 2005
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
a <Source Address, Multicast Group Address> tuple.
5.2. LDP Tunnel Identifier Exchange
When LDP is used for upstream label assignment, the Interface ID TLV
[RFC3472] is used for signaling the Tunnel Identifier. If Ru uses an
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-
ping messages along with the Upstream Assigned Label TLV. The Inter-
face ID TLVs used are the same as the ones specified in the previous
section i.e. the RSVP-TE P2MP LSP TLV and the IP Multicast Tunnel
TLV.
6. Point-to-Multipoint LSPs on a LAN
This section describes one application of upstream label assignment
using RSVP-TE and LDP. Further applications are to be described in
separate documents.
6.1. RSVP-TE P2MP LSPs
[RSVP-TE-P2MP] describes how to setup RSVP-TE P2MP LSPs. On a LAN the
solution described in [RSVP-TE-P2MP] relies on "ingress replication".
A LSR on a LAN, 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 each of
the downstream LSRs on the LAN (say <Rd1...Rdn> that are adjacent to
it in the P2MP LSP.
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
on the LAN, when there are multiple downstream routers on the LAN
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
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
with the following procedures. Assume that Ru and <Rd1...Rdn> support
upstream label assignment.
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
object. This object carries an upstream assigned label, L.
<Rd1...Rdn> "reserve" the upstream assigned label in the separate
Raggarwa & LeRoux [Page 8]
Internet Draftdraft-raggarwa-mpls-rsvp-ldp-upstream-00.txt July 2005
Upstream Neighbor Label Space that they maintain for Ru [MPLS-
UPSTREAM]. 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 [MPLS-MCAST-ENCAPS].
If a subset of <Rd1...Rdn> does not support upstream label assignment
these procedures can still be used between Ru and the remaining sub-
set of <Rd1...Rdn>. Ingress replication and downstream label assign-
ment will continue to be used for LSRs that do not support upstream
label assignment.
6.2. LDP P2MP LSPs
[LDP-P2MP1, LDP-P2MP2] describe how to setup P2MP LSPs using LDP. On
a LAN the solution relies on "ingress replication", as in [RSVP-TE-
P2MP].
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
on the LAN that are adjacent to Ru in that LDP P2MP LSP. It is possi-
ble to achieve this using LDP upstream-assigned labels with the fol-
lowing procedures.
Consider a LSR Rd that receives the LDP P2MP FEC [LDP-P2MP1, LDP-
P2MP2] from its downstream LDP peer. Further the upstream interface
to reach LSR Ru which is the next-hop to the P2MP LSP root address,
Pr, in the LDP P2MP FEC, is a LAN interface. Further Rd and Ru sup-
port upstream-assigned labels. In this case Rd instead of sending a
Label Mapping message as described in [LDP-P2MP1, LDP-P2MP2] sends a
Label Request message to Ru. This Label Request message MUST contain
an Upstream Assigned Label Request TLV. Ru on receiving this message
sends back a Label Mapping message to Rd with an upstream-assigned
label. Processing of the Label Request and Label Mapping messages for
LDP upstream-assigned labels is as described in section 4.2. If Ru
receives a Label Request for an 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 with an upstream-assigned label on the LAN
using the procedures defined in [MPLS-UPSTREAM] and [MPLS-MCAST-
ENCAPS].
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
upstream assigned label request to the next-hop LSR with the lowest
Router ID, if it is desirable for all of them to send the label
request to the same upstream LSR. It is also to be noted that these
Raggarwa & LeRoux [Page 9]
Internet Draftdraft-raggarwa-mpls-rsvp-ldp-upstream-00.txt July 2005
procedures can still be used by Rd and Ru if other LSRs on the LAN do
not support upstream label assignment. Ingress replication and down-
stream label assignment will continue to be used for LSRs that do not
support upstream label assignment.
7. Acknowledgements
Thanks to Yakov Rekhter for his contribution. Thanks to Ina Minei and
Thomas Morin for their comments.
8. References
8.1. Normative References
[RFC3031] "MPLS Architecture", E. Rosen, A. Viswanathan, R. Callon,
RFC 3031.
[MPLS-UPSTREAM] R. Aggarwal, Y. Rekhter, E. Rosen, "MPLS Upstream
Label Assignment and Context Specific Label Space", draft-raggarwa-
mpls-upstream-label-00.txt
[MPLS-MCAST-ENCAPS] T. Eckert, E. Rosen, R. Aggarwal, Y. Rekhter,
draft-rosen-mpls-codepoint-00.txt
[RFC3209] Awduche et. al." "RSVP-TE: Extensions to RSVP for LSP Tun-
nels", RFC 3209, December 2001.
[RFC2119] "Key words for use in RFCs to Indicate Requirement Lev-
els.", Bradner, March 1997
[RFC3472] Ashwood-Smith, P. and L. Berger, Editors, " Generalized
Multi-Protocol Label Switching (GMPLS) Signaling - Constraint-based
Routed Label Distribution Protocol (CR-LDP) Extensions", RFC 3472,
January 2003.
[RFC3473] Berger, L., Editor, "Generalized Multi-Protocol Label
Switching (GMPLS) Signaling - Resource ReserVation Protocol-Traffic
Engineering (RSVP-TE) Extensions", RFC 3473, January 2003.
[RFC3471] Berger, L. Editor, "Generalized Multi-Protocol Label
Switching (GMPLS) Signaling Functional Description", RFC 3471 January
2003.
[RFC3036] L. Andersson, et. al., "LDP Specification", January 2001.
Raggarwa & LeRoux [Page 10]
Internet Draftdraft-raggarwa-mpls-rsvp-ldp-upstream-00.txt July 2005
[RSVP-RESTART] A. Satyanarayana et. al., "Extensions to GMPLS RSVP
Graceful Restart", draft-ietf-ccamp-rsvp-restart-ext-02.txt
8.2. Informative References
[MVPN] E. Rosen, R. Aggarwal [Editors], "Multicast in BGP/MPLS VPNs"
[RSVP-TE-P2MP] R. Aggarwal, D. Papadimitriou, S. Yasukawa [Editors],
"Extensions to RSVP-TE for Point to Multipoint TE LSPs"
[LDP-P2MP1] I. Minei et. al, "Label Distribution Protocol Extensions
for Point-to-Multipoint Label Switched Paths", draft-minei-mpls-ldp-
p2mp-00.txt
[LDP-P2MP2] I. Wijnands et. al., "Multicast Extensions for LDP",
draft-wijnands-mpls-ldp-mcast-ext-00.txt
9. Author Information
Rahul Aggarwal
Juniper Networks
1194 North Mathilda Ave.
Sunnyvale, CA 94089
Email: rahul@juniper.net
Jean-Louis Le Roux
France Telecom
2, avenue Pierre-Marzin
22307 Lannion Cedex
France
E-mail: jeanlouis.leroux@francetelecom.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
Raggarwa & LeRoux [Page 11]
Internet Draftdraft-raggarwa-mpls-rsvp-ldp-upstream-00.txt July 2005
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 specifica-
tion 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 Internet Society (2005). 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 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.
Raggarwa & LeRoux [Page 12]
