Network Working Group Naiming Shen
INTERNET DRAFT BCN Systems
Albert Tian
Expiration Date: April 2005 Jun Zhuang
Redback Networks
D. Papadimitriou
Alcatel
Adrian Farrel
Old Dog Consulting
October 2004
IP Traffic Engineering With Route Switched Paths (RSPs)
draft-shen-ip-te-rsp-03.txt
1. Status of this Memo
By submitting this Internet-Draft, I certify that any applicable
patent or other IPR claims of which I am aware have been disclosed,
or will be 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.
2. Abstract
This document describes a mechanism to establish traffic
engineering IP tunnels. Resource ReSerVation Protocol (RSVP) is
used as a signaling protocol described in Generalized
Multi-Protocol Lable Swithing (GMPLS) RSVP Traffic Engineering
technology, but no MPLS forwarding capability is assumed on the
switched path. IP routing is used to switch IP traffic trunks.
A simple GMPLS RSVP Traffic Engineering extension is needed to
setup the IP Route Switched Paths (RSPs).
Shen, et al Expires April 2005 [Page 1]
Internet Draft IP TE RSP October 2004
3. Introduction
Multi-Protocol Label Switching - Traffic Engineering (MPLS TE) [1, 2]
and Generalized Multi-Protocol Label Switching (GMPLS) [7, 8] Label
Switched Paths (LSP) have been developed and deployed to
automatically route IP traffic away from network failures,
congestion and bottlenecks. Commonly MPLS must be enabled
on the routers through which the LSPs traverse. But some providers
do not enable MPLS as one of the forwarding capabilities in their
networks, thus they can not take the advantage offered by MPLS TE
technologies. Thus by proposing a de-coupling between the TE
control portion from the MPLS forwarding, the possibility is
provided to operators to still benefit from Traffic Engineering
while precluding the mandatory usage of label switching in their
network.
IP tunnels, for instance, GRE tunnel [9], IPv6 over IPv4 tunnel
[10, 11], L2TP tunnel [12], and IPsec tunnel [13], are widely
deployed in ISPs. Currently there is no mechanism to make resource
reservation, guarantee end-to-end QoS service, or setup explicit
routing for those IP tunnels. Other applications such as Next-hop
Fast Reroute [3] for IP traffic in the environment of pure IP
networks may require explicitly routed IP tunnels to reach
the nexthop or next-nexthop nodes.
This document describes a mechanism called IP TE, which is very
similar to MPLS TE and offers similar capabilities as MPLS TE,
but it does not require the network to be MPLS forwarding capable.
GMPLS RSVP-TE protocol extensions are used to signal the setup
of the IP route switched paths (RSPs).
In MPLS TE, the signaling model uses downstream-on-demand label
distribution; while in this IP TE scheme, the egress of a RSP
allocates an IP route entry for the tunnel, and determines the
routing along the path for this tunnel. Those IP routing entries
are no different from other IP routing entries in their routing
table, thus it does not require IP forwarding plane changes in
order to support the IP TE mechanism.
Point-to-point IP tunnels are usually deployed as bi-directional
circuits in networks. This document also describes an optional
mechanism having two RSPs in opposite directions to be used as
a bi-directional IP TE tunnel.
4. Terminology
IP Route Request Characterizes the IP tunnel being requested.
These characteristics include RSP encoding the RSP
payload and are encoded in the Generalized LABEL
REQUEST Object.
Shen, et al Expires April 2005 [Page 2]
Internet Draft IP TE RSP October 2004
IP Route (Label) Contains the information allowing the receiving
node to program its IP forwarding engine; this
information is encoded in the Generalized LABEL
Object.
IP TE Prefix A non-globally routable IP prefix assigned to an
IP TE egress node. This prefix is advertised through
IGP.
IP TE Route An IP route with the IP TE Prefix on egress node
assigned for a terminated RSP.
IP Tunnel A tunnel uses IP as the encapsulation for payload.
Such as GRE, L2TP, IPsec, GTP, IPv6 over IPv4, etc.
Router ID TE Router-ID. It's a stable IP address such as
defined in [14, 15].
RSP IP Route Switched Path. An explicitly routed IP
tunnel setup by the IP TE ingress node. It can be
IPv4 RSP or IPv6 RSP. The route for the IP tunnel
destination address is set along the RSP path along
with all the traffic engineering characteristics.
RSP Egress Address The RSVP tunnel end-point IP address. It is
usually the router-ID of the egress node. This
RSP egress address can be shared among multiple
tunnels.
RSP Tunnel Destination The IP tunnel destination address used
in the packet encapsulation. This tunnel destination
address is unique to each RSP tunnel in the network.
It belongs to the IP TE prefix of the egress node.
TE LSP An MPLS TE Label Switched Path. An explicitly source
routed MPLS LSP tunnel instance along a sequence of
LSRs starting at the ingress LSR and ending at the
egress LSR.
Trailing Loose Segment The last loose segment to the egress node
in a strict/loose explicit path.
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 [16].
In addition, the reader is assumed to be familiar with the
terminology used in [2, 7, 8].
Shen, et al Expires April 2005 [Page 3]
Internet Draft IP TE RSP October 2004
5. IP Traffic Engineering Scheme
A non-globally routable IP address space is reserved for this
scheme in a network. A network can use private address space
or it can be assigned by address allocation authorities for
IPv4 and IPv6. Each egress node is configured with a prefix within
this address space which is large enough to handle all the RSPs
terminated on the node. Each RSP tunnel requires an unique
IP address in this prefix and is allocated by the egress node
on demand.
The ingress node of the RSP decides the path to be setup to the
egress node. It uses the RSVP to establish the tunnel as a special
GMPLS switching mode.
For the Path message, a new C-Type for the Generalized LABEL REQUEST
object referred to as the IP Route Request, is defined in this
document to signal the egress node to allocate an unused address
within the IP TE prefix.
For the Resv message, a new C-Type for the Generalized LABEL object,
referred to as the IP Route (label), is defined to carry the IP
host route along the path back to the ingress node.
The ingress node and all the transit nodes will install this host
route in their routing table towards the egress node of the RSP.
EXPLICIT ROUTE Object MAY also be signaled along the Path
message that used to setup the RSP along the specified path instead
of following the native IP routing. The ingress node will use this
IP host address as the RSP tunnel destination. When a RSP is
brought down, the nodes along the path of this RSP MUST remove
the host route associated with this RSP from their routing table.
When a transit RSP node receives a Path message , it must
determine the nexthop for this path towards the egress point.
If the EXPLICIT ROUTE Object exists, it must follow the same
procedure as described in section 4.3.4 of [2] to determine
the nexthop. When a RSP node receives a Resv message containing the
IP Route Object, It must install the host route of the tunnel
destination address of the RSP with the appropriate nexthop
towards the egress node defined on the path. Since the IP TE prefix
and the RSP tunnel destination address is partitioned in such
a way that each RSP has a unique IP TE address in the domain, the
host route on each node along the RSP path must also be unique.
RECORD ROUTE object processing, for e.g. loop avoidance and
route pinning follows the exactly mechanisms defined in [2].
When initiating a Path message, the ingress node set the Tunnel
Sender Address field of the SENDER_TEMPLATE object to its
Router_ID. The Tunnel Endpoint Address field of the SESSION
object is set by the ingress node to the egress node Router_ID.
Shen, et al Expires April 2005 [Page 4]
Internet Draft IP TE RSP October 2004
The Extended_Tunnel_ID field of the SESSION object is set to either
zero or to an address of the ingress node.
When initiating a Resv message, the egress node set the FILTER_SPEC
object as specified by the incoming SENDER_TEMPLATE object.
5.1 An Example of IP TE RSPs
Consider the RSP nodes are interconnected as the following diagram
Figure 1, the R1 is the ingress of RSPa and R4 is the ingress of
RSPb. Both RSPs have R3 as the egress node:
100.1.1.1 (router-id)
10.1.3.0/24 (IP TE prefix)
o [R1] ==== [R2] ==== [R3]
| || || ^ 10.1.3.1 ^ 10.1.3.2
| || || | |
| +======= [R4] ==== [R5] | RSPa | RSPb
| | |
+------------>----------->--+ |
o---------->----------------+
Figure 1: An example of IP TE RSPs
Assume all the links has the IGP metric of 10, R1 sets up RSPa
with egress node of R3 and explicitly routed (with RSVP ERO
routes in its Path message) through R4 and R5.
IPv4 prefix 10.1.3.0/24 is reserved on R3 as the IP TE prefix
address pool and this IP prefix is advertised through IGP in
the network. When the Path message gets to R3, R3 picks the
first unused address within this TE prefix, 10.1.3.1 to be the
RSP tunnel egress address. The Resv message will be sent back
following the path through R5, R4 and R1 containing the
IP Route Object with host route 10.1.3.1. R1, R4 and R5 will
install the 10.1.3.1/32 in their routing table following the
explicit path towards R3.
RSPb is setup from R4 to R3 through R5, and RSP tunnel
destination address 10.1.3.2 is used. R4 and R5 install the
route 10.1.3.2/32 towards the egress of the RSP.
On R1, when the IP routing is resolved onto 100.1.1.1, the
traffic will be sent through the RSPa with tunnel destination
address of 10.1.3.1.
Shen, et al Expires April 2005 [Page 5]
Internet Draft IP TE RSP October 2004
5.2 IP TE Address Allocation
IP TE prefix(es) are configured on each egress RSP node. The
address should be allocated to handle the maximum number of IP TE
tunnels that could terminate on the node.
This IP TE prefix SHOULD be advertised through the IGP, but it
SHOULD NOT be advertised outside the domain. The host routes
installed for the RSPs are only local to the node, and they
MUST NOT be redistributed into any dynamic routing protocols.
The host routes allocated by the egress node within the IP TE
prefix should be treated as local interface routes on the egress
node. The source address of the tunnel SHOULD use the same
IP address for the Extended Tunnel ID when the RSVP sets up the
RSP. The egress node SHOULD check the validity of the RSP by
examine the source and destination addresses of the IP tunnel.
6. GMPLS RSVP-TE Extension
This document defines three new RSVP object C-Types:
1. Generalized Label Request Object (C-Num = 19, C-Type = 5) to
encode the IP Route Request
2. Generalized Label Object (C-Num = 16, C-Type = 4) to encode the
IPv4 Route (label)
3. Generalized Label Object (C-Num = 16, C-Type = 5) to encode the
IPv6 Route (label)
This is in symmetrical to the (Generalized) Label Request and
(Generalized) Label objects in (G)MPLS TE label switching.
6.1 IP Route Request Object (GMPLS Label Request Object Encoding)
Class-Number = 19, C-Type = 5
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 (19)| C-Type (5) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LSP Enc. Type |Switching Type | G-PID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RSP Key | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
LSP Encoding Type
Shen, et al Expires April 2005 [Page 6]
Internet Draft IP TE RSP October 2004
8 bit field. Must be set to 1.
Switching Type
8 bits field. Must be set to 0xFF and be ignored on receive.
G-PID
16 bit field. An identifier of the protocol type of tunnel
payload using this path. Standard Ethertype [4] values are
used.
RSP Key
It contains a two octet number which may be used between a
pair of RSP nodes to identify two RSPs belong to the same
bi-directional IP tunnel. The UPSTREAM LABEL object used in
GMPLS for bi-directional LSP establishment does not apply here
in the IP TE context. The RSP Key MUST be set to zero if
the RSP is a uni-directional one. The actual method by which
this RSP Key is obtained is beyond the scope of the document.
6.1.1 Handling of GENERALIZED_LABEL_REQUEST object for IP TE
To establish an RSP tunnel the sender creates a Path message with a
GENERALIZED_LABEL_REQUEST object. The GENERALIZED_LABEL_REQUEST
object indicates that an IP host route installation of the IP TE
address for this path is requested and provides an indication of
the network layer protocol that is to be carried over this path.
The GENERALIZED_LABEL_REQUEST object SHOULD be stored in the Path
State Block, so that Path refresh messages will also contain the
GENERALIZED_LABEL_REQUEST object.
A node that recognizes a GENERALIZED_LABEL_REQUEST object, but that
is unable to support it SHOULD send a PathErr with the error code
"Routing problem" with error value TBA to indicate "IP TE routing
install failure".
Upon Path message reception, if a node does not recognize the
GENERALIZED_LABEL_REQUEST object, it SHOULD send a PathErr with
error code "Unknown object class" toward the sender. If a RSVP
router does not recognize the GENERALIZED_LABEL_REQUEST type, it
SHOULD send a PathErr with error code "Unknown object C-Type"
toward the sender. This causes the IP TE tunnel setup request to
fail.
Shen, et al Expires April 2005 [Page 7]
Internet Draft IP TE RSP October 2004
6.2 IP TE Route and (Generalized) LABEL Object Encoding
The IP TE Route is encoded as a (Generalized) LABEL object defined
with a new C-Type for IPv4 and IPv6, respectively, and referred in
the context of this document to as the IP ROUTE object.
The IP ROUTE object MAY be carried in Resv messages. The IP TE
Route for a sender MUST immediately follow the FILTER_SPEC object
for that sender in the Resv message.
This object is defined with the following formats:
Class Number = 16 (Class Name: LABEL), C_Type = 4 (IPv4)
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 (16)| C-Type (4) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IP TE Route (IPv4) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix Length | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The contents of the IP Route of IPv4 is encoded in 8 octets.
4 octets of IPv4 address. 1 octet of prefix length. The prefix
length of value 32 should be used in this scheme.
Class Number = 16 (Class Name: LABEL), C_Type = 5 (IPv6)
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 (16)| C-Type (5) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IP TE Route (IPv6) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IP TE Route (IPv6 continued) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IP TE Route (IPv6 continued) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IP TE Route (IPv6 continued) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix Length | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The contents of the IP Route of IPv6 is encoded in 20 octets.
16 octets of IPv6 address. 1 octet of prefix length.
Shen, et al Expires April 2005 [Page 8]
Internet Draft IP TE RSP October 2004
6.2.1 Handling IP ROUTE Objects in Resv Messages
The egress RSP node allocates the IP TE route in the IP Route
object. Once the IP TE route is allocated or received from a
downstream node, the node formats an IP ROUTE object and
sends the new IP ROUTE object as part of the Resv message to the
previous hop. The transit node and the ingress node SHOULD
install the IP host route into their routing table. The IP ROUTE
object SHOULD be kept in the Reservation State Block.
If a node that does not recognize the GENERALIZED_LABEL C-Type,
it SHOULD send a ResvErr with error code "Unknown object class"
toward the receiver. This causes the reservation to fail.
7. Bi-directional IP Tunnel with RSPs
The IP TE RSP can be used as an uni-directional traffic truck,
the same way as an MPLS LSP is used. This section describes an
optional mechanism that can be applied to allow a pair of RSP
established IP tunnels as a bi-directional circuit. Even though
GMPLS has the bi-directional LSP mechanism, but the bi-directional
LSP is signaled one end LSP, and it can not be used by the other
end of the LSP as a normal routing interface for services and
routing functionalities.
RSVP matches a pair of bi-directional RSPs by identifying three
fields in the RSVP Path messages: tunnel end-point address,
Extended Tunnel ID [2, sections 4.6.1.1], and RSP Key
(section 6.1 above, if there are multiple RSP pairs between the
two RSP nodes). RSVP installs the source and destination
addresses as the outbound data encapsulation to be used by the
bi-directional IP tunnel. The source address is the same as
the Extended Tunnel ID; the destination address is an IP TE
host route assigned by the RSP egress node. RSVP also needs to
inform the IP tunnel about the inbound data encapsulation since
it will not be simply the reverse of the outbound as in most of
the normal IP tunnel encapsulation cases.
(b, a, key1)
a (loopback) rsp1 --------------------->x (IP TE route)
[A] [B] b (loopback)
(IP TE route) y<--------------------- rsp2 [ CONTROL ]
(a, b, key1)
...............
IP tunnel encap (x, a)----------------> [ DATA ]
<------------------ IP tunnel encap (y, b)
Figure 2: RSPs in control plane and IP tunnel in data plane
Shen, et al Expires April 2005 [Page 9]
Internet Draft IP TE RSP October 2004
Assume the IP tunnel is established using a pair of RSPs, rsp1
and rsp2 between node A and B. Further assume A has its loopback
address 'a' and B has its loopback address 'b'. RSVP on A sends
a Path message for rsp1 using (b, a, key1), where 'b' is the
tunnel end-point address, 'a' is the extended tunnel ID, and
key1 is the RSP key. Assume B will assign an IP TE route 'x' for
this rsp1. Similarly, RSVP on B sends a Path message for rsp2
using (a, b, key1), and A will assign an IP TE route 'y' for
this rsp2. Node A and node B match the pair of RSPs by those three
identifiers to belong to a bi-directional circuit. RSVP on Nodes
A and B determine the data encapsulation for the IP tunnel. On
node A, the IP tunnel will use 'x' as the tunnel destination,
and 'a' as the tunnel source for outbound encapsulation. It also
checks the inbound tunnel with destination address of 'y' and
source address of 'b' for the IP tunnel. The RSP Key key1 is not
used by IP tunnel encapsulation and it is only internal to RSVP.
On node B, the operation is the same as above, it sends out with
destination of 'y' and source of 'b', and expects inbound with
destination of 'x' and source of 'a'.
A backup RSP should have a different IP TE route assigned by the
same egress node to protect the primary RSP. When the backup RSP
is used instead of the primary, the RSVP needs to update the
IP tunnel with the new encapsulation.
8. Trailing Loose Segment Optimization
Different from the MPLS TE, since the RSP egress node advertises
the assigned IP TE prefix to the network through IGP, it is possible
to have the nodes along the trailing loose segment not to install
the more specific IP host route for the RSP. Packets belong to the
RSP can be delivered to the egress RSP node following the less
specific IP TE prefix of the egress RSP node. Thus it is possible
to have the first node on the trailing loose segment to send the
Path message directly to the egress of the RSP.
This optimization assumes that there is no traffic engineering
requirement in the trailing loose segment of the RSP. For
applications such as Next-hop Fast Reroute for IP/LDP traffic,
this can be a valid assumption. In that case, a repair path usually
only need to specify one or two short segments close to the ingress
node, thus very few RSVP states need to be kept along the
fastreroute repair paths.
When this optimization is used, the Path message being sent
directly to the egress node MUST NOT include the Router Alert
IP option [6] in its IP header.
Shen, et al Expires April 2005 [Page 10]
Internet Draft IP TE RSP October 2004
9. IANA Considerations
The IP TE proposal requires that IANA allocate a C-Type for
GENERALIZED_LABEL_REQUEST object and a C-Type for GENERALIZED_LABEL
object. IANA also needs to allocate the Error Code for "IP TE
routing install failure" sub-code.
10. Security Considerations
The same RSVP security issues in [5] still apply. The reserved IP
TE prefixes SHOULD not be advertised outside the domain. The
operators can filter the traffic on non-backbone ports to drop
the packets destine to the IP TE prefix blocks. The operators
can also use IP tunnel with keys or authentication.
11. Acknowledgments
The authors would like to thank Changming Liu and Ping Pan for
their comments to this document.
12. References
[1] D. Awduche, J. Malcolm, J. Agogbua, M. O'Dell, J. McManus,
"Requirements for Traffic Engineering Over MPLS", RFC 2702,
September 1999.
[2] Awduche, D., et al, "RSVP-TE: Extensions to RSVP for LSP
tunnels", RFC 3209, December 2001.
[3] Shen, N. and Pan, P., "Nexthop Fast ReRoute for IP and
MPLS", draft-shen-nhop-fastreroute-00.txt, work in progress.
[4] Reynolds, J. and J. Postel, "Assigned Numbers", RFC 1700,
October 1994.
[5] Braden, R., Zhang, L., Berson, S., Herzog, S. and S. Jamin,
"Resource ReSerVation Protocol (RSVP) -- Version 1, Functional
Specification", RFC 2205, September 1997.
[6] Katz, D., "IP Router Alert Option", RFC 2113, February 1997.
[7] L.Berger (Editor) et al., "Generalized Multi-Protocol Label
Switching (GMPLS) Signaling Functional Description,"
RFC 3471, January 2003.
[8] L.Berger (Editor) et al., "Generalized Multi-Protocol Label
Switching (GMPLS) Signaling Resource Reservation Protocol -
Traffic Engineering (RSVP-TE) Extensions," RFC 3473,
January 2003.
Shen, et al Expires April 2005 [Page 11]
Internet Draft IP TE RSP October 2004
[9] Farinacci, D., Li, T., Hanks, S., Meyer, D. and P. Traina,
"Generic Routing Encapsulation (GRE)", RFC 2784, March 2000.
[10] R. Gilligan, E. Nordmark, "Transition Mechanisms for IPv6 Hosts
and Routers", RFC 1933, April 1996.
[11] B. Carpenter, C. Jung, "Transmission of IPv6 over IPv4 Domains
without Explicit Tunnels", RFC 2529, March 1999.
[12] Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn, G.
and B. Palter, "Layer Two Tunneling Protocol - L2TP", RFC 2661,
August 1999.
[13] Kent, S. and R. Atkinson, "IP Encapsulating Security
Payload (ESP)", RFC 2406, November 1998.
[14] H. Smit, T. Li, "Intermediate System to Intermediate System
(IS-IS) Extensions for Traffic Engineering (TE)", RFC 3784,
June 2004.
[15] D. Katz, K. Kompella, D. Yeung, "Traffic Engineering (TE)
Extensions to OSPF Version 2", RFC 3630, September 2003.
[16] S. Bradner, "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, March, 1997.
13. Authors' Addresses
Naiming Shen
BCN Systems
2975 San Ysidro Way
Santa Clara, CA 95051
Email: naiming@bcn-inc.net
Albert Tian
Redback Networks
300 Holger Way
San Jose, CA 95134
Email: tian@redback.com
Jun Zhuang
Redback Networks
300 Holger Way
San Jose, CA 95134
Email: junz@redback.com
Dimitri Papadimitriou
Alcatel
Francis Wellesplein 1,
Shen, et al Expires April 2005 [Page 12]
Internet Draft IP TE RSP October 2004
B-2018 Antwerpen, Belgium
Phone: +32 3 240-8491
Email: dimitri.papadimitriou@alcatel.be
Adrian Farrel
Old Dog Consulting
Phone: +44 (0) 1978 860944
EMail: adrian@olddog.co.uk
The IETF takes no position regarding the validity or scope of any
intellectual property 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; neither does it represent that it
has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11. Copies of
claims of rights made available for publication 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 implementors or users of this specification can
be obtained from the IETF Secretariat.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive
Director.
15. Full Copyright Notice
Copyright (C) The Internet Society (year). 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.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Shen, et al Expires April 2005 [Page 13]