| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
Hi folks,
Luminous has submitted the following draft to ietf iporpr. This draft addresses issues that relate to upper layer interactions to L2 services provided by RPR. Please review the draft and provide us with your valuable feedback.
--------------------------------------------
Sanjay K. Agrawal, Ph.D.
Senior Member of Technical Staff
Luminous Networks
10460 Bubb Road
Cupertino, CA 95014
email: sanjay@xxxxxxxxxxxxxxxxxxxx
<<draft-jogalekar-iporpr-00.txt>>
Network Working Group Prasad Jogalekar,
INTERNET DRAFT Sanjay Agrawal,
Expiration date: May 2001 Vinay Bannai,
Arun Sastry
Luminous Networks, Inc.
November 2000
Expires: May 2001
IP Over Resilient Packet Rings
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
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
Today's metro and core networks are designed to support voice and
video circuit services. With the advent of Internet technology, data
has become the dominant application. This has created a new set of
requirements for metro and core networks that cannot be addressed by
legacy SONET infrastructure. We propose an architecture for Resilient
Packet Rings (RPR) that is designed for Internet data services while
supporting traditional circuit services such as voice and video. RPR
provides flexible mechanisms for multi-service capability including
QoS, routing, fast protection switching, and traffic engineering.
1. Introduction.
Traditional SONET provided point-to-point circuit-switched streaming
Jogalekar, et al [Page 1]
Internet Draft draft-jogalekar-iporpr-00.txt November 2000
services primarily optimized for voice. However, with the advent of
Internet technology, data applications have become the dominant
network applications today. Data is fundamentally a point to
multipoint service with a short connection duration requiring a
packet-switched infrastructure. Alongside with this "new-world"
technology, there is still a need to support streaming services such
as voice and video over this packet-switched infrastructure. This
means that native packet-switched solutions need to provide quality
of service (QoS) and the robustness traditionally associated with
SONET.
Demand for circuit emulation services over IP signifies an important
change in the services and transport paradigm. In legacy networks, IP
traffic is carried over a circuit-switched transport layer. However,
there is a role-reversal in next-generation networks, in which IP is
the ubiquitous transport layer, and premium services are carried over
IP. This paradigm shift is supported by Resilient Packet Rings (RPR.)
This draft proposes an architecture for RPR that provides IP-
optimized packet transport over an optical ring topology. An optical
ring consists of multiple nodes connected in a ring topology with an
option of multiple wavelength add/drop capability at each node. RPR
can utilize SONET MAC for legacy interface, or Gigabit Ethernet to
provide economies of LAN technology. RPR enables two different types
of services over the ring topology, namely the point-to-point (port-
to-port) "cross-connect", and point-to-multipoint "cross-connects".
RPR tunnels enable point-to-point circuit services over the packet
switched ring with protection switching to provide legacy services of
SONET rings. In addition, RPR enables point-to-multipoint services to
support data applications. Existing Layer2 protocols including
spanning tree protocol (IEEE 802.1d) do not support ring topologies.
RPR implements a novel Layer 2 protocol that supports a ring
topology. It provides topology discovery and a choice of under-50 ms
protection switching as an optional service so that link failures can
be rendered transparent to layer 3. Vendors supporting RPR typically
allow a flexible bandwidth management scheme such that based on the
policy, specified traffic can be protected by fast re-routing at the
MAC layer in the event of link, node or wavelength failure(s) while
other traffic may be re-routed at layer-3. In addition, RPR offers
QoS guarantees, and traffic engineering over the ring. Quality of
Service is required to support legacy voice services as well as
emerging voice, video and data applications. Traffic engineering is
required for efficient resource usage as well as for delivering
service level agreements (SLAs). These features of RPR require
seamless integration with layer-3 routing, traffic engineering, and
QoS mechanisms, thus allowing creation of new services over IP. This
draft first discusses the network topology of RPR where we elaborate
on the application of RPR in today's networks. Next, it discusses the
Jogalekar, et al [Page 2]
Internet Draft draft-jogalekar-iporpr-00.txt November 2000
architecture of RPR where we discuss various components including
protection switching, and the proposed mechanisms like quality of
service. Next, it goes over the issues and solutions for integration
with L3 routing. Lastly, it discusses how traffic engineering is
achieved over RPR with MPLS.
2. Network Topology
Mesh topologies provide better resource utilization, since they can
offer N+1 path protection. This is especially the case in long-haul
networks, where fiber links are expensive. However, in metro regions,
where fiber links are relatively cheaper, and administrative
simplicity dictate that the entire transport be provided by a single
provider, rings are the topology of choice. Furthermore, with the
advent of WDM technology, logical meshes can be implemented over a
physical ring to provide the bandwidth efficiency.
Another reason why ring topologies are popular in metro networks is
their ease of configuration and management. They lend themselves to
very fast rerouting in the event of a network failure compared to the
traditional mesh technology. Traditional mesh networks depend on
layer 3 routing to provide rerouting in the event of a network
failure. However since each node in a RPR network has two ways to
reach any other node, it becomes very easy to reroute under failure
conditions by employing novel network topology schemes at the MAC
layer.
Figure 1 below depicts a typical metro cloud where several office
buildings and residential buildings are connected through a metro
ring to their respective ISPs and a central office(s). Each node on
the RPR ring can either be an aggregation point like the central
office site, cable head-end site, ISP cloud or access points like the
residential buildings and office buildings. A typical RPR metro ring
is depicted in figure 1. In this figure, ISPs provide the
connectivity to the outside world for other nodes on the RPR network.
The central office provides the gateway to the POTS (plain old
telephone system) and ISPs. The central office is usually colocated
with providers of legacy voice and data services. The cable head-end
serves out broadcast video to the residential buildings and also
provides ISP connectivity. The head-end is normally colocated with
cable operators or MSOs and data service providers.
Jogalekar, et al [Page 3]
Internet Draft draft-jogalekar-iporpr-00.txt November 2000
* *
ISP cloud ==== RPR_N1=====RPR_N2======Central Office
// \
// \ *
RPR_N6 RPR_N3===Cable Head-end====ISP cloud
\ //
\ //
======RPR_N5========RPR_N4========Office Buildings
Residential Buildings
* Possible aggregation points
Figure 1
========
3. Architecture
Providing multi-services on single metro cloud presents several
challenges. The ability to provide service differentiation, circuit
emulation, bandwidth provisioning, protection from faults on the
metro ring, servicing bandwidth needs are some of the important
components for a RPR network. In the following sections, some of the
architectural components are discussed and their interaction with
other components in a network are studied. This draft presents the
following components that include: Quality of Service, Resource
management, protection switching, Traffic engineering and WDM
switching
3.1 Service differentiation
Traditional networks have supported best effort traffic without
differentiation or QoS guarantees as the primary mode of transport.
Carrying multiple services like native voice, video, circuit emulated
traffic and IP traffic would require that the network components be
able to distinguish between the various services. RPR uses
Differentiated service framework for supporting these services.
Services on the Internet can be categorized as follows:
i. Provisioned delay sensitive service
ii. Provisioned delay insensitive service
iii. Over committed provisioned delay insensitive service
iv. Best effort service
Most of the services level agreement (SLA) can be constructed using
the superposition of above services. The Differentiated Service
framework supports all of the above services on a network cloud. Of
the 8 possible classes, the following five classes have been
Jogalekar, et al [Page 4]
Internet Draft draft-jogalekar-iporpr-00.txt November 2000
standardized in Diffserv:
Express Forwarding (EF):
Targeted to implement Virtual Leased Line services with bandwidth and
delay guarantees. Voice services are the target application for
Express Forwarding class. This can be used to implement delay
sensitive provisioned service.
Assured Forwarding (AF1, AF2, AF3):
Targeted for Internet data applications that need bandwidth
guarantees but not delay. This class will be utilized to carry all
the IP data from customers that have SLA with providers. This can be
utilized to support delay insensitive provisioned class and over-
committed delay insensitive provisioned class.
Best Effort (BE):
This service class utilizes output link bandwidth that is left over
from other class traffic. Whenever congestion occurs, this is the
first class where packets are dropped. This class is targeted for
customers that don't need any bandwidth and delay commitments from
providers. This can be utilized to implement best effort service
class traffic.
Resilient packet rings provide the ability to classify the data flow
based on the content of the data packet according to configured
policy and assign network resources to enable QoS. If the class is
indicated by the customer, class traffic from each customer will be
filtered, policed according to Committed Access Rate (CAR) which is
part of Service Level Agreement (SLA). In RPR, all the excess traffic
from EF will be discarded, while all the excess traffic form AF1,
AF2, AF3 class will be marked down to Best Effort class or dropped
depending on the policy configuration. It is important to note that
resource management is only necessary for provisioned class services.
Critical network resource constraints only prevent new service
commitments in the provisioned class. This doesn't prevent traffic
from non-provisioned classes from using all the resources that are
available in the ring. Thus high link utilizations can be achieved in
the RPR even though only a fraction of the ring resource is used for
provisioned service classes.
3.2 Resource manager
To facilitate protection for fiber breaks or local hardware failures,
it is necessary to have a network-wide knowledge of the network
resources. Also while provisioning for bandwidth a central repository
Jogalekar, et al [Page 5]
Internet Draft draft-jogalekar-iporpr-00.txt November 2000
of network knowledge is consulted to establish guaranteed data paths
and circuits. This knowledge is referred to as a resource manager.
The resource manager typically runs on each node and takes input from
a policy manager, signaling, as well as routing engine to track
demand for resources. The resources usually include available
bandwidth on various wavelengths on the optical ring, buffer
utilizations, resources committed to various classes of service with
their protection requirements.
Resource utilization patterns in metro networks are more dynamic than
those in the core, so the resource manager needs to be able to
atomically handle bandwidth allocation and release at high rates.
3.3 Protection
In addition to QoS, protection switching introduces a new dimension
to service level agreements.
Although L3 protocols such as OSPF respond to network failures, the
convergence time is higher than what can be provided by RPR at L2.
Resilient packet rings are set up to provide ring-wide facility
protection for fiber breaks or local hardware failures. Protection
requires a network-wide knowledge of the network resources consumed
for various provisioned traffic. In the event of rerouting, this
information is consulted to accommodate the various classes of
service.
Some of the real-time services such as toll-quality voice, or an on-
line quote service, require an efficient mechanism to respond to
network faults. The fault scenarios include network link, node, and
hardware failures. Resilient packet ring solutions should provide the
choice to automatically re-route the affected traffic rapidly (under
50 ms). When the IP layer is used as a transport layer to provide
premium services over resilient packet rings, it needs to integrate
with the protection mechanism features offered by resilient packet
rings. Protection switching may result in a change in the usage
pattern of various network resources, and the resource manager needs
to account for it, as does the routing mechanism.
3.4 Traffic Engineering:
Traffic engineering allows finer grain control over how packets are
routed over Resilient Packet Rings. If all the IP packets choose the
same "optimal" route, network resources will be used inefficiently.
Resilient packet ring solutions should support mechanisms to control
the routes taken by a packet over the network. This facilitates a
flexible routing policy, and better resource utilization.
Jogalekar, et al [Page 6]
Internet Draft draft-jogalekar-iporpr-00.txt November 2000
3.5 Wavelength Division Multiplexing Support:
Resilient packet rings with multiple wavelengths allow a flexible
service infrastructure. For example, the policy may specify specific
IP routes take specific wavelengths. Or the wavelengths may be
partitioned based on higher-layer protocols such that a band of
wavelengths is allowed to carry only specified protocols.
Alternatively, the wavelengths can be partitioned along the QoS
lines, such that certain wavelengths are mapped to specific QoS.
WDM provides a new dimension to traffic engineering discussed in
section 3.4. Label switching may be used to hop over different
wavelengths in different sections of the network.
WDM can also be used to implement a physical layer protection
mechanism. Certain wavelengths can be reserved to carry traffic if
there are failures along other failure-protected wavelength(s), thus
allowing N:M protection switching capability. Moreover, a "logical"
mesh topology can be implemented using WDM over a physical ring
topology. This allows more flexibility in provisioning and management
of the network.
3.6 Circuit Emulation Services support:
To support legacy synchronous services, different vendors may support
circuit emulation services over RPR. Circuit emulation services
require jitter control which in turn requires egress jitter-
buffering. In addition, end-to-end synchronization over the ring may
be provided over RPR. Finally, RPR may have to guarantee ordered
delivery of packets at the destination.
4. Interaction with Layer-3 Routing Protocols Over Resilient Packet
Rings
The examples discussed in this section refer to the following figure:
Cloud_1 ==== RPR_N1=====RPR_N2======Cloud_2
// \
// \
RPR_N6 RPR_N3
\ //
\ //
RPR_N5========RPR_N4========Cloud_3
Figure 2
========
Jogalekar, et al [Page 7]
Internet Draft draft-jogalekar-iporpr-00.txt November 2000
The nodes named RPR_* belong to the Resilient Packet Ring,
which has six nodes in this example. Cloud_* represent
network "clouds" outside of the packet ring, which may have
an arbitrary topology.
The links between any two RPR_* nodes are a pair of unidirectional
optical fibers carrying multiple wavelengths. It is possible to have
a different ring topology on different wavelengths, depending on which
wavelengths are dropped at which node. MAC layer protection can be
provided for the traffic on the ring, covering situations such as
unidirectional/bi-directional fiber-chops or certain wavelength
failures, triggering a switch-over to reserved wavelengths.
The links from RPR_* to the network clouds can be SONET, T1/E1,
Ethernet, Gigabit Ethernet etc. and may cover a wide spectrum of
protocols depending on the vendor.
Note that a node "adjacent" to another node on the ring from the
viewpoint of a layer-3 routing protocol may in fact be one or more
hops away on the ring. Thus, a single layer-3 "hop" may map on to one
or more MAC layer "hop"s on the ring (although they may map one-to-one
as a special case.) Protocols such as OSPF can accommodate this by
configuring a "virtual link" between two nodes on the ring, although
they are separated by a segment of RPR (the "transit network") at MAC
layer.
L3 protocols such as OSPF, RIP, IS-IS, or "L2.5" protocols like MPLS,
implement topology discovery and protection switching. RPR provides
these features at L2 protocol level to take advantage of known
topology and provide sub-50ms protection switching like that available
in SONET rings. Now the issue is how the L3/L2.5 protocol takes
advantage of the underlying L2 protection switching services.
There are three possible scenarios:
4.1 Layer-3 routing over RPR with all of the layer-3 traffic
protected by MAC layer
In this case, the MAC-layer routing protocol used on the RPRs is
transparent to layer-3 routing. The entire ring can be thought of as
an "area" within a broader routing domain. Using the MAC layer fast
re-routing provided by RPR, a ring-span failure would be rendered
transparent to layer-3. The protection scenarios include rerouting
around faulty links, nodes or lasers. In case of OSPF, the OSPF HELLO
messages will get re-routed as would the data, and a timeout-triggered
LSA won't happen.
All the adjacencies on the ring that are equidistant (from a
Jogalekar, et al [Page 8]
Internet Draft draft-jogalekar-iporpr-00.txt November 2000
layer-3 viewpoint) remain equidistant even after failure.
The MAC layer routing mechanism will always take the shortest
route on the ring and the layer 3 does not need to know the
cost functions used by the MAC layer. However, policy
based routing can be implemented both at layer-2 and layer-3.
Note that in this mode, OSPF features such as "type of
service routing" and "load balancing" may be ignored by the
MAC layer depending on the policy.
A slight variation of this protection scheme is also possible.
In this case, the span failures on the ring are detected and
conveyed to the layer-3 topology and routing protocol. But in
the interim period before the layer-3 routing converges,
temporary protection is provided at layer-2. Thus, data loss is
still limited to under 50 ms.
4.2 Layer-3 routing over RPR with none of the layer-3 traffic
protected by MAC layer
In this case, a ring span failure on RPR has to be advertised by the
layer-3 routing protocol to the routers outside of the ring. For
example, if any IP route(s) between Cloud_1 and Cloud_3 are affected
by a ring span failure between RPR_N4 and RPR_N5, the ring span
failure has to be advertised to all the nodes belonging to the given
OSPF domain.
In this mode, the MAC layer routing cost function is not transparent
to layer-3 . e.g. OSPF features such as "type of service routing" and
"load balancing" can be used to choose specific path over the RPR,
since the ring MAC layer is exposed to the layer-3 routing function.
However, due to the bidirectional ring topology, there are two
distinct physical paths on the ring that map on to the same "abstract"
ring interface seen by the RPR nodes. In order to avoid any
incorrectness in routing, it is required that all of IP packets
including packets such as OSPF HELLOs, between any two given nodes,
have to follow the same physical path over the ring. This avoids the
case where some of the data may get lost, but the OSPF HELLOs, taking
the "bypass" MAC layer path due to mis-configuration, don't get lost.
In summary, the layer-3 traffic over a resilient packet ring should
either all be protected or all unprotected between any given pair of
nodes. In case it is unprotected, all the layer-3 traffic including
data and control packets should be configured to follow the same
physical path over the ring.
Jogalekar, et al [Page 9]
Internet Draft draft-jogalekar-iporpr-00.txt November 2000
4.3 L3 expects that L2 protection switching events are notified to upper
layers in terms of changes in the cost matrix of that link.
This is especially a must if resource availability after protection
switching is not the same.
All the above three options should be available.
5. Traffic Engineering Over Resilient Packet Rings through MPLS
MPLS enables traffic engineering options on RPR. An RPR node can act
as a Label Edge Router, or Label Switching Router. RPR supports Label
Distribution Protocol [LDP] on each node on the ring. Labels are
typically distributed "Downstream on Demand" while setting up Label
Switched Paths over the packet ring.
Resilient packet rings allow either "explicit routing" of LSP
tunnels, or "hop-by-hop" routing, where the former can follow an
arbitrary path over the ring and the latter follows the path
found by layer-3 routing protocol.
For example, an LSP with a head-end router in Cloud_1 and a
tail-end router in Cloud_2 (figure 2) may have a hop-by-hop
tunnel mapped on to the "clockwise" ring segment between RPR_N1
and RPR_N2, whereas an explicitly routed tunnel over the
"counter-clockwise" ring segment spanning RPR_N1, RPR_N6, RPR_N5,
RPR_N4, RPR_N3, RPR_N2.
LSPs can be set up over Resilient Packet Rings by using the
information provided by IGP, by the signaling protocols ([TERSVP] and
[CRLDP]) and by using the rules programmed in the policy engine. In
addition to the policy-based constraints associated with the route to
be taken by a given LSP, the policy engine also needs to be programmed
for some other attributes of the LSPs (other "constraints") specific
to the Resilient Packet Rings. For example, the protection switching
class of the LSP, wavelength to be used on the ring, MAC layer
protocol to be used on the ring associated with the given wavelength,
etc.
MPLS services may request three modes of operation:
1. Tunnels for which protection explicitly provided by RPR.
2. Tunnels for which protection is not explicitly provided by RPR.
Protected tunnels that do not traverse through RPR.
3. Tunnels for which protection is not explicitly provided by RPR.
Protected tunnels that do traverse through RPR.
Jogalekar, et al [Page 10]
Internet Draft draft-jogalekar-iporpr-00.txt November 2000
We discuss each of these scenarios as follows:
5.1 RPR Protected Tunnels
If TE-RSVP is used for setting up LSPs on a Resilient Packet Ring, the
"Local protection bit" in the SESSION_ATTRIBUTE object [TE_RSVP] may
be used to indicate the choice of protection class on the packet ring
to the policy engine.
As in the case of Section 3, the MPLS tunnels can be re-routed over
the Resilient Packet Ring in the event of a link failure. If a given
LSP is protected at the MAC layer, it is not necessary to establish an
additional "protection tunnel" around the ring. This is automatically
done by the MAC layer of Resilient Packet Rings. In order to
guarantee QoS, Resilient Packet Rings reserve the same amount of
resources along the bypass path available for each LSP between any two
nodes on the ring.
5.2 RPR non-Protected Tunnels. Protected tunnels that traverse
through RPR.
Alternatively, fast rerouting can also be achieved by opting for
unprotected class of service on the packet ring, and setting up
explicit protection tunnels around the ring, to be able to reroute
one or more LSPs in case of a ring segment failure.
MPLS constraint-based rerouting has two main differences with respect
to the MAC layer protection switching on Resilient Packet Rings:
- The MPLS packet forwarding is not destination based, but is based
on the ingress label at the LSR close to the fault.
- The nodes other than those belonging to the backup tunnel(s)
need not know about the failure.
For example, LSP re-routing using appropriate policy can be
achieved as follows:
Jogalekar, et al [Page 11]
Internet Draft draft-jogalekar-iporpr-00.txt November 2000
push a swap a->b pop b
Cloud_1 ==== RPR_N1=====RPR_N2======Cloud_2
// \
swap a->b, push c pop f
// \
RPR_N6 RPR_N3
\ //
swap c->d swap e->f
\ //
RPR_N5========RPR_N4========Cloud_3
swap d->e
Figure 3
========
Assume a label switched path, say LSP_1 has a head-end in Cloud_1
and tail-end in Cloud_2. Suppose it rides over the link RPR_N1
and RPR_N2. In the event of a failure of this link, RPR_N1's policy
engine makes the following change - in addition to swapping the
label from "a" to "b", it also pushes another label "c" on the
label stack and sends it out on the "bypass" interface towards
RPR_N6. The packet follows the path as shown and reaches RPR_N2
with the same label "b" as in the case when there was no span break.
(In fact, this label could even have been different, since it was
received on a different ring interface on RPR_N2 - whose policy
engine can distinguish the several cases).
Note that another LSP with a head-end in Cloud_1 and a tail_end in
cloud_2, but with a different ingress label on RPR_N1 (say, "a*" ) can
be protected using the same bypass-LSP. Thus, any number of LSPs
requiring protection can be rerouted over an arbitrary number of
bypass-LSPs. Note that the bypass LSP could even leave the Resilient
Packet Ring at node RPR_N4, say, and use external IP routes between
Cloud_3 and Cloud_2 to reach the destination, if so programmed in the
policy engine.
5.3 Tunnels for which protection is not explicitly provided by RPR.
Protected tunnels that do not traverse through RPR
RPR protection provided to MPLS is vulnerable to node RPR_N1 failure in
Figure 3, in which case tunnels setup in both directions will be
rendered useless. Thus, service providers may not want backup tunnels
to go though the RPR node through which the first tunnel was set up.
If the original tunnel (tunnel 1) was set up through RPR_N1, the backup
tunnel (tunnel 2) may enter a node (RPR_N6.) RPR_N6 needs to
route the backup tunnel in the direction opposite of the tunnel 1
entering RPR_N1. This can be done through RSVP-TE explicit object
Jogalekar, et al [Page 12]
Internet Draft draft-jogalekar-iporpr-00.txt November 2000
which indicates the fault groups which includes Tunnel 1. Fault group
is a concept under discussion at MPLS working group that helps
set up backup tunnels in the spatially diverse region of the
network. Node RPR_N6 looking at the fault group in the RSVP object
will route backup tunnel in the opposite direction of the ring to
tunnel 1 to provide spatial diversity for fault protection.
6. Conclusions.
Resilient Packet Rings have MAC-layer features such as fast
protection switching which need special treatment while
integrating with layer-3 protocols. These features facilitate
the creation of new IP-level services, with additional dimensions
to QoS such as resilience and jitter-buffering.
Layer-3 features need to be carefully inter-worked with the
resilient packet ring features, i.e., routing protocols,
signaling, policy engine, and traffic engineering need to account
for these in order to avoid incorrect behavior in case of faults.
Supporting layer-3 protocols over a resilient packet ring
opens up new dimensions for SLAs as discussed in this draft.
7. Acknowledgements
We thank Jason Fan and Raj Sharma for their valuable input
and comments.
8. References
[CRLDP] B. Jamoussi, et al, "Constraint-Based LSP Setup using LDP",
draft-ietf-mpls-cr-ldp-04.txt, work in progress, July 2000
[LDP] L. Andersson, P. Doolan, N. Feldman, A. Fredette, B. Thomas,
"LDP Specification", draft-ietf-mpls-ldp-11.txt, work in progress,
August 2000.
[RED] S. Floyd and V. Jacobson, "Random Early Detection Gateways for
Congestion Avoidance", IEEE/ACM Transactions on Networking,
August 1993
[TERSVP] D. Awduche, L. Berger, D. Gan, T. Li, V. Srinivasan, G. Swallow,
"RSVP-TE: Extensions to RSVP for LSP Tunnels",
draft-ietf-mpls-rsvp-lsp-tunnel-07.txt, work in progress, August 2000.
9. Security Considerations
The issues raised in this document do not introduce any additional
security considerations.
Jogalekar, et al [Page 13]
Internet Draft draft-jogalekar-iporpr-00.txt November 2000
10. Authors' addresses
Prasad Jogalekar
Luminous Networks, Inc.
10460 Bubb Road
Cupertino, CA 95014
Phone: +1-408-342-6400
Email: prasad@xxxxxxxxxxxxxxxxxxxx
Sanjay Agrawal
Luminous Networks, Inc.
10460 Bubb Road
Cupertino, CA 95014
Phone: +1-408-342-6400
Email: sanjay@xxxxxxxxxxxxxxxxxxxx
Vinay Bannai
Luminous Networks, Inc.
10460 Bubb Road
Cupertino, CA 95014
Phone: +1-408-342-6400
Email: vinay@xxxxxxxxxxxxxxxxxxxx
Arun Sastry
Luminous Networks, Inc.
10460 Bubb Road
Cupertino, CA 95014
Phone: +1-408-342-6400
Email: arun@xxxxxxxxxxxxxxxxxxxx
11. Full Copyright Statement
Copyright (C) The Internet Society (2000). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published and
distributed, in whole or in part, without restriction of any kind,
provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
Jogalekar, et al [Page 14]
Internet Draft draft-jogalekar-iporpr-00.txt November 2000
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
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."
Jogalekar, et al [Page 15]