As per Relevance of the word different, we have this rfc below:
Network Working Group T.
Request for Comments: 2430 Juniper
Category: Informational Y.
Cisco
October 1998
A Provider Architecture
Differentiated Services and Traffic
(PASTE
Status of this
This memo provides information for the Internet community. It
not specify an Internet standard of any kind. Distribution of
memo is unlimited
Copyright
Copyright (C) The Internet Society (1998). All Rights Reserved
1.0
This document describes the Provider Architecture for
Services and Traffic Engineering (PASTE) for Internet
Providers (ISPs). Providing differentiated services in ISPs is
challenge because the scaling problems presented by the sheer
of flows present in large ISPs makes the cost of maintaining per-
state unacceptable. Coupled with this, large ISPs need the
to perform traffic engineering by directing aggregated flows
traffic along specific paths
PASTE addresses these issues by using Multiprotocol Label
(MPLS) [1] and the Resource Reservation Protocol (RSVP) [2] to
a scalable traffic management architecture that
differentiated services. This document assumes that the reader
at least some familiarity with both of these technologies
2.0
In common usage, a packet flow, or a flow, refers to a
stream of packets, distributed over time. Typically a flow has
fine granularity and reflects a single interchange between hosts
such as a TCP connection. An aggregated flow is a number of
that share forwarding state and a single resource reservation along
sequence of routers
Li & Rekhter Informational [Page 1]
RFC 2430 PASTE October 1998
One mechanism for supporting aggregated flows is Multiprotocol
Switching (MPLS). In MPLS, packets are tunneled by wrapping them
a minimal header [3]. Each such header contains a label,
carries both forwarding and resource reservation semantics.
defines mechanisms to install label-based forwarding
along a series of Label Switching Routers (LSRs) to construct a
Switched Path (LSP). LSPs can also be associated with
reservation information
One protocol for constructing such LSPs is the Resource
Protocol (RSVP) [4]. When used with the Explicit Route Object (ERO
[5], RSVP can be used to construct an LSP along an explicit
[6].
To support differentiated services, packets are divided into
traffic classes. For conceptual purposes, we will discuss
different traffic classes: Best Effort, Priority, and
Control. The exact number of subdivisions within each class is to
defined
Network Control traffic primarily consists of routing protocols
network management traffic. If Network Control traffic is dropped
routing protocols can fail or flap, resulting in network instability
Thus, Network Control must have very low drop preference. However
Network Control traffic is generally insensitive to moderate
and requires a relatively small amount of bandwidth. A
bandwidth guarantee is sufficient to insure that Network
traffic operates correctly
Priority traffic is likely to come in many flavors, depending on
application. Particular flows may require bandwidth guarantees
jitter guarantees, or upper bounds on delay. For the purposes
this memo, we will not distinguish the subdivisions of
traffic. All priority traffic is assumed to have an
resource reservation
Currently, the vast majority of traffic in ISPs is Best
traffic. This traffic is, for the most part, delay insensitive
reasonably adaptive to congestion
When flows are aggregated according to their traffic class and
the aggregated flow is placed inside a LSP, we call the result
traffic trunk, or simply a trunk. The traffic class of a packet
orthogonal to the LSP that it is on, so many different trunks,
with its own traffic class, may share an LSP if they have
traffic classes
Li & Rekhter Informational [Page 2]
RFC 2430 PASTE October 1998
3.0
The next generation of the Internet presents special challenges
must be addressed by a single, coordinated architecture. While
architecture allows for distinction between ISPs, it also defines
framework within which ISPs may provide end-to-end
services in a coordinated and reliable fashion. With such
architecture, an ISP would be able to craft common agreements for
handling of differentiated services in a consistent fashion
facilitating end-to-end differentiated services via a composition
these agreements. Thus, the goal of this document is to describe
architecture for providing differentiated services within the ISPs
the Internet, while including support for other forthcoming
such as traffic engineering. While this document addresses the
of the ISPs, its applicability is not limited to the ISPs. The
architecture could be used in any large, multiprovider
needing differentiated services
This document only discusses unicast services. Extensions to
architecture to support multicast are a subject for future research
One of the primary considerations in any ISP architecture
scalability. Solutions that have state growth proportional to
size of the Internet result in growth rates exceeding Moore's law
making such solutions intractable in the long term. Thus,
that use mechanisms with very limited growth rates are
preferred
Discussions of differentiated services to date have
resulted in solutions that require per-flow state or per-
queuing. As the number of flows in an ISP within the "default-
zone of the Internet" scales with the size of the Internet,
growth rate is difficult to support and argues strongly for
solution with lower state requirements. Simultaneously,
differentiated services is a significant benefit to most ISPs.
support would allow providers to offer special services such
priority for bandwidth for mission critical services for
willing to pay a service premium. Customers would contract with
for these services under Service Level Agreements (SLAs). Such
agreement may specify the traffic volume, how the traffic is handled
either in an absolute or relative manner, and the compensation
the ISP receives
Differentiated services are likely to be deployed across a single
to support applications such as a single enterprise's Virtual
Network (VPN). However, this is only the first wave of
implementation. Closely following this will be the need
differentiated services to support extranets, enterprise VPNs
Li & Rekhter Informational [Page 3]
RFC 2430 PASTE October 1998
span ISPs, or industry interconnection networks such as the ANX [7].
Because such applications span enterprises and thus span ISPs,
is a clear need for inter-domain SLAs. This document discusses
technical architecture that would allow the creation of such inter
domain SLAs
Another important consideration in this architecture is the advent
traffic engineering within ISPs. Traffic engineering is the
to move trunks away from the path selected by the ISP's IGP and
a different path. This allows an ISP to route traffic around
points of congestion in its network, thereby making more
use of the available bandwidth. In turn, this makes the ISP
competitive within its market by allowing the ISP to pass lower
and better service on to its customers
Finally, the need to provide end-to-end differentiated
implies that the architecture must support consistent inter-
differentiated services. Most flows in the Internet today
multiple ISPs, making a consistent description and treatment
priority flows across ISPs a necessity
4.0 Components of the
The Differentiated Services Backbone architecture is the
of several different mechanisms that, when used in a coordinated way
achieve the goals outlined above. This section describes each of
mechanisms used in some detail. Subsequent sections will then
the interoperation of these mechanisms
4.1 Traffic
As described above, packets may fall into a variety of
traffic classes. For ISP operations, it is essential that packets
accurately classified before entering the ISP and that it is
easy for an ISP device to determine the traffic class for
particular packet
The traffic class of MPLS packets can be encoded in the three
reserved for CoS within the MPLS label header. In addition,
classes for IPv4 packets can be classified via the IPv4 ToS byte
possibly within the three precedence bits within that byte.
that the consistent interpretation of the traffic class,
of the bits used to indicate this class, is an important feature
PASTE
Li & Rekhter Informational [Page 4]
RFC 2430 PASTE October 1998
In this architecture it is not overly important to control
packets entering the ISP have a particular traffic class. From
ISP's perspective, each Priority packet should involve some
premium for delivery. As a result the ISP need not pass judgment
to the appropriateness of the traffic class for the application
It is important that any Network Control traffic entering an ISP
handled carefully. The contents of such traffic must also
carefully authenticated. Currently, there is no need for
generated external to a domain to transit a border router of the ISP
4.2
As described above, traffic of a single traffic class that
aggregated into a single LSP is called a traffic trunk, or simply
trunk. Trunks are essential to the architecture because they
the overhead in the infrastructure to be decoupled from the size
the network and the amount of traffic in the network. Instead,
the traffic scales up, the amount of traffic in the trunks increases
not the number of trunks
The number of trunks within a given topology has a worst case of
trunk per traffic class from each entry router to each exit router
If there are N routers in the topology and C classes of service,
would be (N * (N-1) * C) trunks. Fortunately, instantiating
many trunks is not always necessary
Trunks with a single exit point which share a common internal
can be merged to form a single sink tree. The computation
to determine if two trunks can be merged is straightforward. If
when a trunk is being established, it intersects an existing
with the same traffic class and the same remaining explicit route
the new trunk can be spliced into the existing trunk at the point
intersection. The splice itself is straightforward: both
trunks will perform a standard label switching operation, but
result in the same outbound label. Since each sink tree created
way touches each router at most once and there is one sink tree
exit router, the result is N * C sink trees
The number of trunks or sink trees can also be reduced if
trunks or sink trees for different classes follow the same path
This works because the traffic class of a trunk or sink tree
orthogonal to the path defined by its LSP. Thus, two trunks
different traffic classes can share a label for any part of
topology that is shared and ends in the exit router. Thus,
entire topology can be overlaid with N trunks
Li & Rekhter Informational [Page 5]
RFC 2430 PASTE October 1998
Further, if Best Effort trunks and individual Best Effort flows
treated identically, there is no need to instantiate any Best
trunk that would follow the IGP computed path. This is because
packets can be directly forwarded without an LSP. However,
engineering may require Best Effort trunks to be treated
from the individual Best Effort flows, thus requiring
instantiation of LSPs for Best Effort trunks. Note that
trunks must be instantiated because end-to-end RSVP packets
support the aggregated Priority flows must be tunneled
Trunks can also be aggregated with other trunks by adding a new
to the stack of labels for each trunk, effectively bundling
trunks into a single tunnel. For the purposes of this document,
is also considered a trunk, or if we need to be specific, this
be called an aggregated trunk. Two trunks can be aggregated if
share a portion of their path. There is no requirement on the
length of the common portion of the path, and thus the
requirements for forming an aggregated trunk are beyond the scope
this document. Note that traffic class (i.e., QoS indication)
propagated when an additional label is added to a trunk, so trunks
different classes may be aggregated
Trunks can be terminated at any point, resulting in a
of traffic. The obvious consequence is that there needs to
sufficient switching capacity at the point of deaggregation to
with the resultant traffic
High reliability for a trunk can be provided through the use of
or more backup trunks. Backup trunks can be initiated either by
same router that would initiate the primary trunk or by
backup router. The status of the primary trunk can be ascertained
the router that initiated the backup trunk (note that this may
either the same or a different router as the router that
the primary trunk) through out of band information, such as the IGP
If a backup trunk is established and the primary trunk returns
service, the backup trunk can be deactivated and the primary
used instead
4.3
Originally RSVP was designed as a protocol to install
associated with resource reservations for individual
originated/destined to hosts, where path was determined
destination-based routing. Quoting directly from the
specifications, "The RSVP protocol is used by a host, on behalf of
application data stream, to request a specific quality of
(QoS) from the network for particular data streams or flows
[RFC2205].
Li & Rekhter Informational [Page 6]
RFC 2430 PASTE October 1998
The usage of RSVP in PASTE is quite different from the usage of
as it was originally envisioned by its designers. The
difference is that RSVP is used in PASTE to install state
applies to a collection of flows that all share a common path
common pool of reserved resources. The second difference is
RSVP is used in PASTE to install state related to forwarding
including label switching information, in addition to
reservations. The third difference is that the path that this
is installed along is no longer constrained by the destination-
routing
The key factor that makes RSVP suitable for PASTE is the set
mechanisms provided by RSVP. Quoting from the RSVP specifications
"RSVP protocol mechanisms provide a general facility for creating
maintaining distributed reservation state across a mesh of
or unicast delivery paths." Moreover, RSVP provides a
extensibility mechanism by allowing for the creation of new
Objects. This flexibility allows us to also use the
provided by RSVP to create and maintain distributed state
information other than pure resource reservation, as well as
the creation of forwarding state in conjunction with
reservation state
The original RSVP design, in which "RSVP itself transfers
manipulates QoS control parameters as opaque data, passing them
the appropriate traffic control modules for interpretation" can
be extended to include explicit route parameters and label
parameters. Just as with QoS parameters, RSVP can transfer
manipulate explicit route parameters and label binding parameters
opaque data, passing explicit route parameters to the
forwarding module, and label parameters to the appropriate
module
Moreover, an RSVP session in PASTE is not constrained to be
between a pair of hosts, but is also used between pairs of
that act as the originator and the terminator of a traffic trunk
Using RSVP in PASTE helps consolidate procedures for several tasks
(a) procedures for establishing forwarding along an explicit route
(b) procedures for establishing a label switched path, and (c) RSVP'
existing procedures for resource reservation. In addition,
functions can be cleanly combined in any manner. The main
of this consolidation comes from an observation that the above
tasks are not independent, but inter-related. Any alternative
accomplished each of these functions via independent sets
procedures, would require additional coordination between functions
adding more complexity to the system
Li & Rekhter Informational [Page 7]
RFC 2430 PASTE October 1998
4.4 Traffic
The purpose of traffic engineering is to give the ISP precise
over the flow of traffic within its network. Traffic engineering
necessary because standard IGPs compute the shortest path across
ISP's network based solely on the metric that has
administratively assigned to each link. This computation does
take into account the loading of each link. If the ISP's network
not a full mesh of physical links, the result is that there may
be an obvious way to assign metrics to the existing links such
no congestion will occur given known traffic patterns.
engineering can be viewed as assistance to the routing
that provides additional information in routing traffic
specific paths, with the end goal of more efficient utilization
networking resources
Traffic engineering is performed by directing trunks along
paths within the ISP's topology. This diverts the traffic away
the shortest path computed by the IGP and presumably onto
links, eventually arriving at the same destination. Specification
the explicit route is done by enumerating an explicit list of
routers in the path. Given this list, traffic engineering trunks
be constructed in a variety of ways. For example, a trunk could
manually configured along the explicit path. This would
configuring each router along the path with state information
forwarding the particular label. Such techniques are currently
for traffic engineering in some ISPs today
Alternately, a protocol such as RSVP can be used with an
Route Object (ERO) so that the first router in the path can
the trunk. The computation of the explicit route is beyond the
of this document but may include considerations of policy, static
dynamic bandwidth allocation, congestion in the topology and
configured alternatives
4.5 Resource
Priority traffic has certain requirements on capacity and
handling. To provide differentiated services, the ISP'
infrastructure must know of, and support these requirements.
mechanism used to communicate these requirements dynamically is RSVP
The flow specification within RSVP can describe many
of the flow or trunk. An LSR receiving RSVP information about a
or trunk has the ability to look at this information and
accept or reject the reservation based on its local policy.
policy is likely to include constraints about the traffic
functions that can be supported by the network and the
capacity that the network is willing to provide for Priority traffic
Li & Rekhter Informational [Page 8]
RFC 2430 PASTE October 1998
4.6 Inter-Provider SLAs (IPSs
Trunks that span multiple ISPs are likely to be based on
agreements and some other external considerations. As a result,
of the common functions that we would expect to see in this type
architecture is a bilateral agreement between ISPs to
differentiated services. In addition to the obvious compensation
this agreement is likely to spell out the acceptable traffic
policies and capacities to be used by both parties
Documents similar to this exist today on behalf of Best
traffic and are known as peering agreements. Extending a
agreement to support differentiated services would effectively
an Inter-Provider SLA (IPS). Such agreements may include the
of differentiated services that one ISP provides to the other ISP,
well as the upper bound on the amount of traffic associated with
such service that the ISP would be willing to accept and carry
the other ISP. Further, an IPS may limit the types of
services and an upper bound on the amount of traffic that
originate from a third party ISP and be passed from one signer of
IPS to the other
If the expected costs associated with the IPS are not symmetric,
parties may agree that one ISP will provide the other ISP
appropriate compensation. Such costs may be due to inequality
traffic exchange, costs in delivering the exchanged traffic, or
overhead involved in supporting the protocols exchanged between
two ISPs
Note that the PASTE architecture provides a technical basis
establish IPSs, while the procedures necessary to create such
are outside the scope of PASTE
4.7 Traffic shaping and
To help support IPSs, special facilities must be available at
interconnect between ISPs. These mechanisms are necessary to
that the network transmitting a trunk of Priority traffic does
within the agreed traffic characterization and capacity.
simplistic example of such a mechanism might be a token
system, implemented on a per-trunk basis. Similarly, there need
be mechanisms to insure, on a per trunk basis, that an ISP
a trunk receives only the traffic that is in compliance with
agreement between ISPs
Li & Rekhter Informational [Page 9]
RFC 2430 PASTE October 1998
4.8 Multilateral
Trunks may span multiple ISPs. As a result, establishing
particular trunk may require more than two ISPs. The result would
a multilateral IPS. This type of agreement is unusual with
to existing Internet business practices in that it requires
participating parties for a useful result. This is also
because without a commonly accepted service level definition,
will need to be a multilateral definition, and this definition
not be compatible used in IPSs between the same parties
Because this new type of agreement may be a difficulty, it may
some cases be simpler for certain ISPs to establish aggregated
through other ISPs and then contract with customers to
their trunks. In this way, trunks can span multiple ISPs
requiring multilateral IPSs
Either or both of these two alternatives are possible and
within this architecture, and the choice is left for the
participants to make on a case-by-case basis
5.0 The Provider Architecture for differentiated Services and
Engineering (PASTE
The Provider Architecture for differentiated Services and
Engineering (PASTE) is based on the usage of MPLS and RSVP
mechanisms to establish differentiated service connections
ISPs. This is done in a scalable way by aggregating
flows into traffic class specific MPLS tunnels, also known as
trunks
Such trunks can be given an explicit route by an ISP to define
placement of the trunk within the ISP's infrastructure, allowing
ISP to traffic engineer its own network. Trunks can also
aggregated and merged, which helps the scalability of
architecture by minimizing the number of individual trunks
intermediate systems must support
Special traffic handling operations, such as specific
algorithms or drop computations, can be supported by a network on
per-trunk basis, allowing these services to scale with the number
trunks in the network
Agreements for handling of trunks between ISPs require both
documentation and conformance mechanisms on both sides of
agreement. As a trunk is unidirectional, it is sufficient for
transmitter to monitor and shape outbound traffic, while the
polices the traffic profile
Li & Rekhter Informational [Page 10]
RFC 2430 PASTE October 1998
Trunks can either be aggregated across other ISPs or can be
subject of a multilateral agreement for the carriage of the trunk
RSVP information about individual flows is tunneled in the trunk
provide an end-to-end reservation. To insure that the return
traffic is handled properly, each trunk must also have another
running in the opposite direction. Note that the reverse tunnel
be a different trunk or it may be an independent tunnel
at the same routers as the trunk. Routing symmetry between a
and its return is not assumed
RSVP already contains the ability to do local path repair. In
event of a trunk failure, this capability, along with the ability
specify abstractions in the ERO, allows RSVP to re-establish
trunk in many failure scenarios
6.0 Traffic flow in the PASTE
As an example of the operation of this architecture, we consider
example of a single differentiated flow. Suppose that a user
to make a telephone call using a Voice over IP service. While
call is full duplex, we can consider the data flow in each
in a half duplex fashion because the architecture
symmetrically
Suppose that the data packets for this voice call are created at
node S and need to traverse to node D. Because this is a voice call
the data packets are encoded as Priority packets. If there is
granularity within the traffic classes, these packets might
encoded as wanting low jitter and having low drop preference
Initially this is encoded into the precedence bits of the IPv4
byte
6.1 Propagation of RSVP
To establish the flow to node D, node S first generates an RSVP
message which describes the flow in more detail. For example,
flow might require 3kbps of bandwidth, be insensitive to jitter
less than 50ms, and require a delay of less than 200ms. This
is passed through node S's local network and eventually appears
node S's ISP. Suppose that this is ISP F
ISP F has considerable latitude in its options at this point.
requirement on F is to place the flow into a trunk before it
F's infrastructure. One thing that F might do is to perform
admission control function at the first hop router. At this point,
would determine if it had the capacity and capability of carrying
flow across its own infrastructure to an exit router E. If
admission control decision is negative, the first hop router
Li & Rekhter Informational [Page 11]
RFC 2430 PASTE October 1998
inform node S using RSVP. Alternately, it can propagate the
PATH message along the path to exit router E. This is simply
operation of RSVP on a differentiated flow
At exit router E, there is a trunk that ISP F maintains that
ISP X, Y, and Z and terminates in ISP L. Based on BGP
information or on out of band information, Node D is known to be
customer of ISP L. Exit router E matches the flow requirements
the RSVP PATH message to the characteristics (e.g.,
capacity) of the trunk to ISP L. Assuming that the requirements
compatible, it then notes that the flow should be aggregated into
trunk
To insure that the flow reservation happens end to end, the RSVP
message is then encapsulated into the trunk itself, where it
transmitted to ISP L. It eventually reaches the end of the trunk
where it is decapsulated by router U. PATH messages are
propagated all the way to the ultimate destination D
Note that the end-to-end RSVP RESV messages must be carefully
by router U. The RESV messages from router U to E must return via
tunnel back to router E
RSVP is also used by exit router E to initialize and maintain
trunk to ISP L. The RSVP messages for this trunk are not
within the trunk itself but the end-to-end RSVP messages are.
existence of multiple overlapping RSVP sessions in PASTE
straightforward, but requires explicit enumeration when
particular RSVP sessions
6.2 Propagation of user
Data packets created by S flow through ISP F's network following
flow reservation and eventually make it to router E. At that point
they are given an MPLS label and placed in the trunk. Normal
switching will propagate this packet across ISP X's network.
that the same traffic class still applies because the class
is propagated from the precedence bits of the IPv4 header to the
bits in the MPLS label. As the packet exits ISP X's network, it
be aggregated into another trunk for the express purpose
tranisiting ISP Y
Again, label switching is used to bring the packet across ISP Y'
network and then the aggregated trunk terminates at a router in
Z's network. This router deaggregates the trunk, and forwards
resulting trunk towards ISP L. This trunk transits ISP Z
terminates in ISP L at router U. At this point, the data packets
removed from the trunk and forwarded along the path computed by RSVP
Li & Rekhter Informational [Page 12]
RFC 2430 PASTE October 1998
6.3 Trunk establishment and
In this example, there are two trunks in use. One trunk runs
ISP F, through ISPs X, Y and Z, and then terminates in ISP L.
other aggregated trunk begins in ISP X, transits ISP Y and
in ISP Z
The first trunk may be established based on a multilateral
between ISPs F, X, Z and L. Note that ISP Y is not part of
multilateral agreement, and ISP X is contractually responsible
providing carriage of the trunk into ISP Z. Also per this agreement
the tunnel is maintained by ISP F and is initialized and
through the use of RSVP and an explicit route object that lists ISP'
X, Z, and L. Within this explicit route, ISP X and ISP L are
as strict hops, thus constraining the path so that there may not
other ISPs intervening between the pair of ISPs F and X and the
Z and L. However, no constraint is placed on the path between ISPs
and Z. Further, there is no constraint placed on which
terminates the trunk within L's infrastructure
Normally this trunk is maintained by one of ISP F's routers
to ISP X. For robustness, ISP F has a second router adjacent to
X, and that provides a backup trunk
The second trunk may be established by a bilateral agreement
ISP X and Y. ISP Z is not involved. The second trunk is
so that it terminates on the last hop router within Y'
infrastructure. This tunnel is initialized and maintained
the use of RSVP and an explicit route that lists the last hop
within ISP Y's infrastructure. In order to provide redundancy in
case of the failure of the last hop router, there are
explicit routes configured into ISP X's routers. These routers
select one working explicit route from their configured list
Further, in order to provide redundancy against the failure of X'
primary router, X provides a backup router with a backup trunk
6.4
Note that in this example, there are no single points of failure
the traffic is within ISP F's network. Each trunk has a backup
to protect against the failure of the primary trunk. To
against the failure of any particular router, each trunk can
configured with multiple explicit route objects that terminate at
of several acceptable routers
Li & Rekhter Informational [Page 13]
RFC 2430 PASTE October 1998
7.0 Security
Because Priority traffic intrinsically has more 'value' than
Effort traffic, the ability to inject Priority traffic into a
must be carefully controlled. Further, signaling concerning
traffic has to be authenticated because it is likely that
signaling information will result in specific accounting
eventually billing for the Priority services. ISPs are cautioned
insure that the Priority traffic that they accept is in fact from
known previous hop. Note that this is a simple requirement
fulfill at private peerings, but it is much more difficult at
interconnects. For this reason, exchanging Priority traffic
public interconnects should be done with great care
RSVP traffic needs to be authenticated. This can possibly be
through the use of the Integrity Object
8.0
The Provider Architecture for differentiated Services and
Engineering (PASTE) provides a robust, scalable means of
differentiated services in the Internet. It provides scalability
aggregating flows into class specific MPLS tunnels. These tunnels
also called trunks, can in turn be aggregated, thus leading to
hierarchical aggregation of traffic
Trunk establishment and maintenance is done with RSVP,
advantage of existing work in differentiated services.
routes within the RSVP signaling structure allow providers to
traffic engineering by placing trunks on particular links in
network
The result is an architecture that is sufficient to scale to meet
needs and can provide differentiated services in the large,
traffic engineering, and continue to grow with the Internet
8.1
Inspiration and comments about this document came from Noel Chiappa
Der-Hwa Gan, Robert Elz, Lisa Bourgeault, and Paul Ferguson
Li & Rekhter Informational [Page 14]
RFC 2430 PASTE October 1998
9.0
[1] Rosen, E., Viswanathan, A., and R. Callon, "A
Architecture for MPLS", Work in Progress
[2] Braden, R., Zhang, L., Berson, S., Herzog, S., and S. Jamin
"Resource ReSerVation Protocol (RSVP) -- Version 1
Specification", RFC 2205, September 1997.
[3] Rosen, E., Rekhter, Y., Tappan, D., Farinacci, D., Fedorkow,, G.,
Li, T., and A. Conta, "MPLS Label Stack Encoding", Work
Progress
[4] Davie, B., Rekhter, Y., Rosen, E., Viswanathan, A., and V
Srinivasan, "Use of Label Switching With RSVP", Work in Progress
[5] Gan, D.-H., Guerin, R., Kamat, S., Li, T., and E. Rosen, "
up Reservations on Explicit Paths using RSVP", Work in Progress
[6] Davie, B., Li, T., Rosen, E., and Y. Rekhter, "Explicit
Support in MPLS", Work in Progress
[7] http://www.anxo.com
10.0 Authors'
Tony
Juniper Networks, Inc
385 Ravendale Dr
Mountain View, CA 94043
Phone: +1 650 526 8006
Fax: +1 650 526 8001
EMail: tli@juniper.
Yakov
cisco Systems, Inc
170 W. Tasman Dr
San Jose, CA 95134
EMail: yakov@cisco.
Li & Rekhter Informational [Page 15]
RFC 2430 PASTE October 1998
11. Full Copyright
Copyright (C) The Internet Society (1998). All Rights Reserved
This document and translations of it may be copied and furnished
others, and derivative works that comment on or otherwise explain
or assist in its implementation may be prepared, copied,
and distributed, in whole or in part, without restriction of
kind, provided that the above copyright notice and this paragraph
included on all such copies and derivative works. However,
document itself may not be modified in any way, such as by
the copyright notice or references to the Internet Society or
Internet organizations, except as needed for the purpose
developing Internet standards in which case the procedures
copyrights defined in the Internet Standards process must
followed, or as required to translate it into languages other
English
The limited permissions granted above are perpetual and will not
revoked by the Internet Society or its successors or assigns
This document and the information contained herein is provided on
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED,
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE
Li & Rekhter Informational [Page 16]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
