One document matched: draft-raggarwa-rsvpte-pw-00.txt
Network Working Group Rahul Aggarwal
Internet Draft Kireeti Kompella
Expiration Date: December 2004 Arthi Ayyangar
Juniper Networks
Dimitri Papadimitriou
Alcatel
Peter Busschbach
Lucent
Setup and Maintenance of Pseudowires using RSVP-TE
draft-raggarwa-rsvpte-pw-00.txt
Status of this Memo
By submitting this Internet-Draft, I certify that any applicable
patent or IPR claims of which I am aware have been disclosed, and any
of which I become aware will be disclosed, in accordance with RFC
3668.
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.
draft-raggarwa-rsvpte-pw-00.txt [Page 1]
Internet Draft draft-raggarwa-rsvpte-pw-00.txt June 2004
Abstract
This document describes procedures for using Resource Reservation
Protocol-Traffic Engineering (RSVP-TE) for signaling Pseudowires
(PWs). One motivation is the signaling of PW QoS. The other is the
setup of a multi-hop PW, for example, to span multiple domains.
RSVP-TE provides mechanisms for QoS signaling and these can be
leveraged for signaling PW QoS. It also provides the ability to
signal bi-directional MPLS Label Switched Paths (LSP) with explicit
routes. This can be used for signaling multi-hop PWs that require
explicit routing. RSVP-TE also provides the ability to establish non-
adjacent or targeted signaling sessions.
Conventions used in this document
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 RFC-2119 [KEYWORDS].
1. Terminology
Single-hop PW: A PW that comprises only two PW demultiplexor
allocation nodes.
Multi-hop PW: A PW that comprises more than two PW demultiplexor
allocation nodes.
2. Introduction
A PW is a mechanism that carries the essential elements of an
emulated service from one PE to another over a PSN [PW-ARCH]. A point
to point PW is bi-directional. A "PW header", consisting of a (PW)
demultiplexor field is prepended to the encapsulated PDU. The
resulting parcket is then transmitted to the remote endpoint of the
PW over one or more "PSN tunnels"; this may require an additional
header to be prepended to the packet. When the packet arrives at the
remote endpoint of the PW, the PW demultiplexor is what enables the
receiver to identify the particular PW on which the packet has
arrived.
In the case that it is not desirable to establish a single PSN tunnel
between the two endpoints of a PW or the PW needs to be explicitly
routed across multiple hops for QoS provisioning or administrative
reasons, a multi-hop PW is needed. In this case each PW hop uses a
separate PSN tunnel. The PW demultiplexor may have to be changed at
draft-raggarwa-rsvpte-pw-00.txt [Page 2]
Internet Draft draft-raggarwa-rsvpte-pw-00.txt June 2004
each hop. An example scenario where a multi-hop PW is needed is one
that spans multiple domains, where edge-to-edge PSNs may not be
possible for scaling or administrative reasons. Each domain may have
a different PSN technology.
[LDP-PW] describes procedures for using the Label Distribution
Protocol [LDP] for the setup and maintenance of single-hop PWs. The
PW demultiplexor field is a MPLS label, and PW demultiplexor
signaling performs label exchange between two PEs.
If one wants to signal multi-hop, explicitly routed PWs and/or PWs
with QoS characteristics, new mechanisms are required. The protocol
architecture of RSVP-TE is an appropriate fit for these applications
(as well as basic demultiplexor exchange). This is because RSVP-TE
has the mechanisms for signaling QoS and for explicit routing. RSVP-
TE extensions described in [RFC3473] also provide mechanisms to setup
bi-directional LSPs. It also has mechanisms that can be used for PW
identification, setup and maintenance.
Multi-hop PWs traverse multiple PSN tunnels and the PSN tunnels may
be setup using Generalized MPLS (GMPLS) signaling [RFC3473]. Hence
another useful applicability scope of the proposed approach is PWs
over MPLS PSNs supporting GMPLS RSVP-TE [RFC 3473] as well as other
switching technologies within the scope of GMPLS.
This document describes procedures for using RSVP-TE for PW signaling
motivated by the goals mentioned in the previous paragraph. This
document assumes familiarity with [RFC3209] and [RFC3473].
3. Motivation
This section describes the motivations behind this document.
3.1. PW QoS
A PW is a mechanism that carries the essential elements of an
emulated service from one PE to another over a PSN [PW-ARCH]. The
emulated service is offered by a SP to a customer over an attachment
circuit (AC). Hence a PW can also be considered as a mechanism that
is used to inter-connect two ACs over a PSN. A Service Level
Agreement (SLA) is often associated with such an emulated service.
Packet loss and delay bounds in a given time interval are examples of
a SLA that a SP may provide to a customer. Such a SLS translates into
QoS, for example bandwidth, that is associated with the PW. Providing
this QoS on the PW requires the following:
a) Assigning QoS parameters to each AC in conformance with the
SLA. These QoS parameters get associated with the PW that is used to
draft-raggarwa-rsvpte-pw-00.txt [Page 3]
Internet Draft draft-raggarwa-rsvpte-pw-00.txt June 2004
carry traffic from the AC.
b) Policing on the AC on both the PEs based on the QoS parameters
c) Call admission control (CAC) of the PW into the PSN tunnel
which is used to transmit the PW packets. This assumes that the PSN
tunnel can be signaled with QoS. To achieve this RSVP-TE can be used
as the PSN tunnel signaling protocol.
The procedures described above require that the two ends of a PW be
associated with the same QoS parameters. In current PW deployments
this is achieved using configuration. However it is desirable to
signal this QoS information from one end of the PW to another. This
is beneficial for PW operation and management. This is also
desirable for multi-hop PWs described in the next section. It should
also be possible to change the QoS characteristics of a PW without
any packet loss on the PW.
3.2. Multi-Hop PWs
A PW by default inter-connects the ACs between two PEs that exchange
the PW demultiplexor. These two PEs are the PW demultiplexor
allocation nodes. This document uses the term multi-hop PW to refer
to a PW that comprises more than two PW demultiplexor allocation
nodes. One way to conceptualize this is as multiple PWs that are
stitched together and are still part of the same end to end PW.
A multi-hop PW is needed when it is not desirable to establish a
single PSN tunnel between the two endpoints of a PW or the PW needs
to be explicitly routed across multiple hops for QoS provisioning or
administrative reasons. The PW demultiplexor allocation nodes along
a multi-hop PW need to be explicitly specified. This requires a PW
explicit route.
A practical application of a multi-hop PWs is the setup of a PW
across multiple domains. For instance across multiple IGP domains or
ASs or domains with different PSN technologies.
Consider an inter-AS PW that is set up by PE1 in AS1 to PE2 in AS2.
It may be desirable to control the exit point of this PW in AS1 and
select the entry point of the PW in AS2. Traffic accounting per PW is
one motivation for this. Another motivation is to avoid setting up a
full mesh of end-to-end PWs between ASs. The inter-AS PW may be
explicitly routed through ASBR1 in AS1, which is PE1's next-hop to
reach PE2. ASBR1 in turn may explicitly route the PW through ASBR2
which is its next-hop to reach PE2. ASBR2 will complete the PW
signaling. In this case there is one signaling protcol adjacency to
signal the PW between PE1 and ASBR1; one between ASBR1 and ASBR2; and
one between ASBR2 and PE2. PE1, ASBR1, ASBR2 and PE2 are PW
demultiplexor allocation points.
draft-raggarwa-rsvpte-pw-00.txt [Page 4]
Internet Draft draft-raggarwa-rsvpte-pw-00.txt June 2004
3.3. PW Redundancy
It may be desirable to backup one PW with another. For instance a CE
may be dual homed to a PE using two different ACs. One AC is the
primary while the other is the backup. Both these ACs are attached to
the same remote AC. The remote PE can setup a PW for each of the two
local ACs. One of these PWs is the primary PW while the other is the
backup PW. The backup PW is setup apriori and is in standby mode
incase the primary PW fails. The primary and backup PWs may also be
multi-hop PWs and may be signaled with QoS. The multi-hop primary
and backup PWs may be routed over different PW demultiplexor
allocation points. If they pass through the same PW demultiplexor
points QoS double booking must be avoided between these two PWs as
only one of them is active at a given time.
4. Motivation for using RSVP-TE
This section describes why RSVP-TE is an appropriate fit for
addressing the motivations described in section 3.
RSVP-TE is used to setup explicitly routed Label Switched Paths
(LSPs). Multiple LSPs may belong to the same tunnel. A LSP is
identified using a SESSION object and a SENDER_TEMPLATE object. The
SESSION object carries a tunnel identifier (TUNNEL_ID) to identify a
tunnel. It also carries the tunnel destination. The SENDER_TEMPLATE
carries the source of the tunnel and a LSP_ID to identify a specific
LSP. An ingress LSR is defined as the LSR that originates the LSP. An
egress LSR is defined as the endpoint of the LSP. LSP setup consists
of signaling in the forward and the reverse direction. The ingress
LSR originates a Path message to the egress LSR and the egress LSR
responds with a Resv message. The LSP is successfully established
when the ingress LSR receives the Resv message.
[RFC3209] defines the setup of unidirectional LSPs. [RFC3473] extends
this to bidirectional LSPs. Hence a Path message sent by the ingress
LSR can be used to signal a bidirectional LSP.
RSVP signaling messages can be exchanged between adjacent or non-
adjacent nodes [LSP-HIER].
The specific building blocks of RSVP-TE that make it an appropriate
fit for solving the problems addressed by this document are discussed
below. In the following discussion a LSP refers to a bidirectional
LSP.
draft-raggarwa-rsvpte-pw-00.txt [Page 5]
Internet Draft draft-raggarwa-rsvpte-pw-00.txt June 2004
4.1. QoS Signaling
RSVP-TE is designed to setup LSPs that are signaled with QoS
Parameters. The Path message carries the QoS specification that is
requested by the ingress LSR in the SENDER_TSPEC object. The
SENDER_TSPEC object carries the traffic specification generated by
RSVP session sender i.e the ingress LSR. The SENDER_TSPEC object is
forwarded unchanged and delivered to both transit and egress LSRs.
The FLOWSPEC object carries reservation request information generated
by receivers i.e. the QoS desired by egress LSRs. The information
content of the FLOWSPEC object flows upstream towards the ingress
LSR. Each transit LSR uses the FLOWSPEC object for CAC and to setup
the LSP QoS in hardware in the direction from the ingress LSR to the
egress LSR and also in the reverse direction.
This mechanism can be used for signaling PW QoS.
4.2. Explicit Routing
As discussed in section 3 the primary requirement of signaling multi-
hop PWs is the specification of an explicit route. RSVP-TE allows a
LSP to be setup using an EXPLICIT_ROUTE_OBJECT (ERO). An ERO contains
a sequence of hops that the LSP must be routed through. The semantics
allow an intermediate hop to insert hops in the ERO.
4.3. Sharing QoS Resources between LSPs
RSVP-TE allows multiple LSPs to belong to the same tunnel. These LSPs
can be signaled such that they share QoS resources with each other
between common hops. This can be used for PW redundancy. A backup PW
can be setup to share QoS resources with the primary PW between
common hops. It can also be used for modifying the QoS of a PW using
RSVP-TE make-before-break [RFC3209].
4.4. Bidirectional Label Allocation
RSVP-TE [RFC3209] sets up unidirectional LSPs and provides the
mechanism to signal the downstream label in the Resv message.
[RFC3473] extends this to signal bidirectional LSPs allowing the
upstream label to be carried in the Path message. A PW is
bidirectional and RSVP-TE bidirectional label allocation mechanisms
will be used for PW label exchange with a single signaling session.
draft-raggarwa-rsvpte-pw-00.txt [Page 6]
Internet Draft draft-raggarwa-rsvpte-pw-00.txt June 2004
4.5. LSP Hierarchy
[RFC3209] has the notion of LSP hierarchy. A LSP can be advertised as
a Forwarding Adjacency (FA) to rest of the domain, allowing other
nodes in the domain to use the FA LSP as a link for computing traffic
engineered paths for other LSPs [LSP-HIER]. One or more LSPs (inner
LSPs) can be carried over the FA LSP (outer LSP). When RSVP-TE is
used for PW signaling and PSN tunnels are also setup using RSVP-TE,
the PSN tunnels may be advertised as FA LSPs. If this is the case
the multi-hop PW origination point can use the FA LSPs to traffic
engineer the path of the multi-hop PW, which is the inner LSP.
5. Design Overview
This section gives an overview of how RSVP-TE can be used for
addressing the motivations described in section 3.
5.1. Mapping RSVP-TE LSPs to PWs
This document maps a PW to a bidirectional LSP. A PW is identified by
the SESSION object, SENDER_TEMPLATE object and a new PW TLV that is
carried in a new SENDER_TSPEC C-Type. The PW TLV is discussed in
section 6.1. Mapping a PW to a LSP allows the use of QoS signaling,
explicit and record routing, resource sharing as well as as any other
RSVP capability that can be mapped to an LSP
5.2. Non-Adjacent Signaling
Non-adjacent signaling between PW demultiplexor allocation points is
used for signaling PWs with RSVP-TE. This allows RSVP-TE signaling
messages to be exchanged between hops that are not directly adjacent.
5.3. Single-Hop PW Label Signaling
This document proposes that RSVP-TE can also be used for signaling
single-hop PW demultiplexors. This is done using bidirectional label
allocation mechanisms. It is conceivable that a different protocol
can be used for signaling single-hop PW demultiplexors when RSVP-TE
is used for multi-hop PW signaling or PW QoS signaling. LDP [LDP-PW]
can be used for this purpose. This may be useful if a network has
currently deployed LDP for single-hop PW setup with or without QoS
and wishes to setup multi-hop PWs. In that case a PW association is
needed between LDP and RSVP-TE. This is for further study.
draft-raggarwa-rsvpte-pw-00.txt [Page 7]
Internet Draft draft-raggarwa-rsvpte-pw-00.txt June 2004
5.4. Single Sided Signaling
RSVP-TE PW sessions are originated by one end of the PW. The other
end of the PW completes the signaling by responding to this request.
This follows the single sided signaling concept that has been
proposed earlier in [LDP-PW]. In this model both the PW ends do not
initiate asynchronous signaling messages. It is only one end that
initiates the PW setup.
6. Procedures
6.1. RSVP-TE PW Identification
A LSP is mapped to a PW. A PW is identified by the SESSION object,
the SENDER_TEMPLATE object and a new PSEUDOWIRE TLV (PW TLV) included
as part of a new SENDER_TSPEC/FLOWSPEC object. Details of the
SENDER_TSPEC/FLOWSPEC object encoding carried in the Path and Resv
message, respectively, will be specified in the next revision. The PW
TLV identifies the individual PW. It also allows the receiver of the
RSVP-TE Path message to realize that the signaled session is being
used to setup a PW. This identifier can either be a 32 bit number or
it can have generalized semantics. A different TLV type is used for
both these cases. The generalized PW TLV will be specified in the
next revision. The encoding when the PW TLV contains a 32 bit number
follows.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TLV Type = TBD | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PW ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The PW type, presence of the control word and any other PW specific
parameters are signaled in the TSPEC. Details will be specified in
the next revision.
6.2. Single-Hop PW Setup
This document proposes the use of RSVP-TE for exchanging single-hop
PW labels when RSVP-TE is used for addressing the motivations
described in Section 3. This is accomplished by using bidirectional
label allocation mechanisms. The PW is signaled as a bidirectional
LSP by the local PE using a non-adjacent i.e. targeted Path message.
draft-raggarwa-rsvpte-pw-00.txt [Page 8]
Internet Draft draft-raggarwa-rsvpte-pw-00.txt June 2004
The remote PE can associate PW semantics with the LSP based on the PW
parameters carried in the SENDER_TSPEC object including the PW TLV.
The remote PE adds a route that is used to map traffic from the AC
into the PW. The inner label of the route's next-hop is the PW label
(i.e. the upstream label) received from the PE that signaled the PW.
When a Path message containing an upstream_PW label is received by
the remote PE, the latter first verifies that the upstream label is
acceptable. If the label is not acceptable, the receiver MUST issue a
PathErr message with a "Routing problem/Unacceptable PW label value"
indication. The remote PE also adds a MPLS route for the received PW
label with the AC as the next-hop. The remote PE then generates a
Resv message and sends it to the local PE along with a PW label (i.e.
the downstream label). The local PE completes the PW setup by adding
the local AC route and the MPLS PW label route. Contention resolution
for bi-directional LSPs follows rules specified in Section 3.2 of
[RFC3473].
The SENDER_TSPEC object that carries the traffic specification
generated by the RSVP session sender MUST be delivered unchanged to
the egress PE. The FLOWSPEC object that carries reservation request
information generated by receivers. The information content of the
FLOWSPEC object flows upstream towards ingress PE. For a particular
sender PE, for a single-hop PW, the contents of the FLOWSPEC object
received in a Resv message SHOULD be identical (or lower, for the QoS
parameters, see Section 6.3) to the contents of the SENDER_TSPEC
object sent in the corresponding Path message. If the objects do not
match, a ResvErr message with a "Traffic Control Error/Bad Flowspec
value" error SHOULD be generated.
When a bidirectional LSP is torn down, both upstream and downstream
labels are invalidated and it is no longer valid to send data using
the associated labels.
The outer label can be the transport LSP label when using MPLS
tunnels. It can also be any other PSN tunnel encapsulation: eg. IP or
GRE.
Refresh reduction [RFC2961] can be used to reduce the refresh and
processing overhead of RSVP-TE control messages.
6.3. Single-Hop PW QoS Signaling
A RSVP-TE LSP is established for the PW between the two PEs using
non-adjacent signaling. This is a bidirectional LSP. This LSP is
signaled with the QoS parameters desired by the local PE for the PW.
These parameters are carried in the SENDER_TSPEC object in the Path
Message and in the FLOWSPEC object in the Resv message.
draft-raggarwa-rsvpte-pw-00.txt [Page 9]
Internet Draft draft-raggarwa-rsvpte-pw-00.txt June 2004
The SENDER_TSPEC object MUST be delivered unchanged to the egress PE.
This object also includes the PW TLV used to identify the PW.
The egress PE MUST verify that the incoming SENDER_TSPEC QoS
parameters can be supported for the requested LSP. If the requested
value(s) can not be supported, the egress PE MUST generate a PathErr
message with a "Traffic Control Error/Service unsupported" indication
(see [RFC2205]).
The remote PE responds with a Resv message that contains in the
FLOWSPEC object the QoS parameters desired by the remote PE. This
value is either the same as the QoS requested in the SENDER_TSPEC or
lower. Both the local and the remote PE use the FLOWSPEC for
administering PW QoS. If the objects do not match the PW TLV or the
QoS requested parameters are larger, a ResvErr message with a
"Traffic Control Error/Bad Flowspec value" error SHOULD be generated.
QoS signaling mechanisms in RSVP-TE are fairly mature. They have been
defined for various QoS service models. Also RSVP-TE [RFC3209] and
various extensions to it [RFC3473] describe mechanisms for signaling
QoS for different media such as ATM, Frame Relay, optical interfaces
etc. Based on the AC being inter-connected, the PW LSP is signaled
with an appropriate SENDER_TSPEC/FLOWSPEC object.
RSVP-TE make-before-break procedures can be used to modify PW QoS
without impacting PW traffic.
6.4. Multi-Hop PW Signaling
A multi-hop PW that requires explicit routing is signaled using a
RSVP-TE bidirectional LSP with a PW TLV in the SENDER_TSPEC object
and an explicit route encoded in the EXPLICIT_ROUTE object. The
ingress LSR sends a Path message with the destination address being
the multi-hop PW end point. The explicit route specifies the hops
that the PW must be routed through. Intermediate nodes may insert
hops in the explicit route as the ingress LSR may specify the
explicit route partially. PW labels that are used to send data in the
direction from the egress LSR to the ingress LSR are allocated by
each PW demultiplexor allocation hop and propagated in the Path
message. The SENDER_TSPEC object is propagated unchanged to the
multi-hop PW endpoint which uses the PW TLV to identify the PW. The
egress of the multi-hop PW responds with a Resv message. This message
contains the FLOWSPEC object, which is used to administer the QoS at
each intermediate node as the Resv message is propagated to the
ingress LSR. PW labels that are used to send data in the direction
from the ingress LSR to the egress LSR are allocated by each PW
demultiplexor allocation hop and propagated in the Resv message.
draft-raggarwa-rsvpte-pw-00.txt [Page 10]
Internet Draft draft-raggarwa-rsvpte-pw-00.txt June 2004
In addition to the processing of the SENDER_TSPEC and FLOWSPEC object
described in Section 6.3 at the ingress and egress LSR, here,
intermediate PW demultiplexors MUST verify that the node itself and
the interfaces on which the LSP will be established can support the
requested QoS parameters. If the requested value(s) can not be
supported, the receiver node MUST generate a PathErr message with a
"Traffic Control Error/Service unsupported" indication (see
[RFC2205]).
6.5. Redundant PWs
A local PE can signal a redundant PW using the same SESSION object as
the primary PW and by varying the LSP-ID in the SENDER_TEMPLATE
object. This allows intermediate hops to share QoS between the two.
In the case of failure of the primary PW the local PE can try to
switch traffic to the backup PW.
Note that the procedures described in this document allow a CE to be
dual homed to the same PE. Procedures for dual homing a CE to
different PEs will be described in the next revision.
7. Security Considerations
Security considerations from [RFC3209] and [RFC3473] apply to this
document.
8. IANA Considerations
TBD
9. Acknowledgments
Thanks to Chaitanya Kodeboyina and Sasha Vainshtein for discussing
the ideas presented here.
draft-raggarwa-rsvpte-pw-00.txt [Page 11]
Internet Draft draft-raggarwa-rsvpte-pw-00.txt June 2004
10. References
10.1. Normative References
[RFC3209] Awduche, D., et al, "RSVP-TE: Extensions to RSVP for LSP
tunnels", RFC 3209, December 2001.
[RFC3473] L. Berger, Ed.. Generalized Multi-Protocol Label Switching
(GMPLS) Signaling Resource Reservation Protocol-Traffic
Engineering (RSVP-TE) Extensions, RFC 3473 January 2003.
[RFC2210] Wroclawski, J., "The Use of RSVP with IETF
Integrated Services", RFC 2210, September 1997.
[LSP-HIER] K. Kompella, Y. Rekhter, "LSP Hierarchy with Generalized
MPLS TE", draft-ietf-mpls-lsp-hierarchy-08.txt
[RFC2961] Berger, L., Gan, D., Swallow, G., Pan, P., Tommasi,
F. and S. Molendini, "RSVP Refresh Overhead
Reduction Extensions", RFC 2961, April 2001.
[RFC] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[PW-ARCH] "PWE3 Architecture" Bryant, et al.,
draft-ietf-pwe3-arch-07.txt, March 2003.
10.2. Informative References
[LSP-Ping] K. Kompella et. al., "Detecting MPLS Data Plane Failures",
draft-ietf-mpls-lsp-ping-03.txt
[VCCV] T. Nadeau, R. Aggarwal, "Pseudo Wire (PW) Virtual Circuit
Connection Verification ((VCCV)",
draft-ietf-pwe3-vccv-03.txt
[LDP] Andersson, L., et al, "LDP Specification", RFC 3036
[LDP-PW] L. Martini et. al.,"Pseudowire Setup and Maintenance
using LDP",
draft-ietf-pwe3-control-protocol-08.txt
[MPLS-ST] "MPLS Label Stack Encoding", E. Rosen, Y. Rekhter,
D. Tappan, G. Fedorkow, D. Farinacci, T. Li, A. Conta.
RFC3032
draft-raggarwa-rsvpte-pw-00.txt [Page 12]
Internet Draft draft-raggarwa-rsvpte-pw-00.txt June 2004
Author Information
Rahul Aggarwal
Juniper Networks
1194 North Mathilda Ave.
Sunnyvale, CA 94089
Email: rahul@juniper.net
Kireeti Kompella
Juniper Networks
1194 North Mathilda Ave.
Sunnyvale, CA 94089
Email: kireeti@juniper.net
Arthi Ayyangar
Juniper Networks
1194 North Mathilda Ave.
Sunnyvale, CA 94089
Email: arthi@juniper.net
Dimitri Papadimitriou
Alcatel
Francis Wellesplein 1,
B-2018 Antwerpen, Belgium
Phone: +32 3 240-8491
Email: Dimitri.Papadimitriou@alcatel.be
Peter Busschbach
Lucent Technologies
67 Whippany Road
Whippany, NJ 07981
email: busschbach@lucent.com
11. Intellectual Property
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
draft-raggarwa-rsvpte-pw-00.txt [Page 13]
Internet Draft draft-raggarwa-rsvpte-pw-00.txt June 2004
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.
12. Full Copyright Statement
Copyright (C) The Internet Society (2004). 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 is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS 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.
13. Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
draft-raggarwa-rsvpte-pw-00.txt [Page 14]
| PAFTECH AB 2003-2026 | 2026-04-22 09:33:44 |