< draft-ietf-mpls-framework-01.txt   draft-ietf-mpls-framework-02.txt >
Network Working Group R. Callon Network Working Group R. Callon
INTERNET DRAFT Ascend Communications INTERNET DRAFT Ascend Communications
<draft-ietf-mpls-framework-01.txt> P. Doolan <draft-ietf-mpls-framework-02.txt> P. Doolan
Cisco Systems Ennovate Networks
N. Feldman N. Feldman
IBM Corp. IBM Corp.
A. Fredette A. Fredette
Bay Networks Bay Networks
G. Swallow G. Swallow
Cisco Systems Cisco Systems
A. Viswanathan A. Viswanathan
IBM Corp. IBM Corp.
July 30, 1997 November 21, 1997
Expires Jan. 30, 1998 Expires May 21, 1998
A Framework for Multiprotocol Label Switching A Framework for Multiprotocol Label Switching
Status of this Memo Status of this Memo
This document is an Internet-Draft. Internet-Drafts are working This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas, documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts. working documents as Internet-Drafts.
skipping to change at page 2, line 16 skipping to change at page 2, line 16
proposed protocol architecture for MPLS. This redundancy will be proposed protocol architecture for MPLS. This redundancy will be
reduced over time, with the overall discussion of issues moved to be reduced over time, with the overall discussion of issues moved to be
in this document, and the selection of specific approaches and in this document, and the selection of specific approaches and
specification of the protocol contained in the protocol architecture specification of the protocol contained in the protocol architecture
and other related documents. and other related documents.
Acknowledgments Acknowledgments
The ideas and text in this document have been collected from a number The ideas and text in this document have been collected from a number
of sources and comments received. We would like to thank Jim Luciani, of sources and comments received. We would like to thank Jim Luciani,
Andy Malis, Yakov Rekhter, Eric Rosen, and Vijay Srinivasan for their Andy Malis, Rayadurgam Ravikanth, Yakov Rekhter, Eric Rosen, Vijay
inputs and ideas. Srinivasan, and Pasi Vananen for their inputs and ideas.
1. Introduction and Requirements 1. Introduction and Requirements
1.1 Overview of MPLS 1.1 Overview of MPLS
The primary goal of the MPLS working group is to standardize a base The primary goal of the MPLS working group is to standardize a base
technology that integrates the label swapping forwarding paradigm technology that integrates the label swapping forwarding paradigm
with network layer routing. This base technology (label swapping) is with network layer routing. This base technology (label swapping) is
expected to improve the price/performance of network layer routing, expected to improve the price/performance of network layer routing,
improve the scalability of the network layer, and provide greater improve the scalability of the network layer, and provide greater
skipping to change at page 10, line 30 skipping to change at page 10, line 30
NHC Next Hop (NHRP) Client NHC Next Hop (NHRP) Client
NHS Next Hop (NHRP) Server NHS Next Hop (NHRP) Server
VC Virtual Circuit VC Virtual Circuit
VCI Virtual Circuit Identifier VCI Virtual Circuit Identifier
VPI Virtual Path Identifier VPI Virtual Path Identifier
1.5 Motivation for MPLS
This section describes the expected and potential benefits of the
MPLS over existing schemes. Specifically, this section discusses the
advantages of MPLS over previous methods for building core networks
(i.e., networks for internet service providers or for major corporate
backbones). The potential advantages of MPLS in campus and local area
networks are not discussed in this section.
There are currently two commonly used methods for building core IP
networks: (i) Networks of datagram routers in which the core of the
network is based on the datagram routers; (ii) Networks of datagram
routers operating over an ATM core. In order to describe the
advantages of MPLS, it is necessary to know which alternate to MPLS
we are using for the comparison. This section is therefore split into
two sections: Section 1.5.1 describes the advantages of MPLS when
compared to a pure datagram routed network. Section 1.5.2 describes
the advantages of MPLS when compared to an IP over ATM network.
This section does not provide a complete list of requirements for
MPLS. For example, Multipoint to Point Trees are important for MPLS
to scale. However, datagram forwarding naturally acts in this way
(since multiple sources are merged automatically), and the ATM forum
is currently adding support for multipoint to point to the ATM
standards. The ability to do MPTs is therefore important to MPLS, but
does not represent an advantage over either datagram routing or IP
over ATM, and therefore is not mentioned in this section.
1.5.1 Benefits Relative to Use of a Router Core
1.5.1.1 Simplified Forwarding
Label swapping allows packet forwarding to be based on an exact match
for a short label, rather than a longest match algorithm applied to a
longer address as is required for normal datagram forwarding. In
addition, the label headers used with MPLS are simpler than the
headers typically used with datagram protocols such as IP. This in
turn implies that MPLS allows a much simpler forwarding paradigm
relative to datagrams, and implies that it is easier to build a high
speed router using MPLS.
Whether this simpler forwarding operation will result in availability
of LSRs which can operate at higher speeds than datagram routers is
controversial, and probably depends upon implementation details.
There are some parts of the network, such as at hierarchical
boundaries, where datagram IP forwarding at high speed will be
required. This implies that implementation of a high speed router is
highly desirable. In addition, there are currently multiple companies
building high speed routers which will allow IP packets to be
forwarded at very high speed. At speeds at least up to OC48, it
appears that once the one-time engineering is completed, the per-unit
cost associated with IP forwarding will be a small fraction of the
overall equipment cost.
However, there are also many existing routers which can benefit from
the simpler forwarding allowed by MPLS. In addition, there are some
routers being built with implementations that will benefit from the
simpler forwarding available with MPLS.
1.5.1.2 Efficient Explicit Routing
Explicit routing (aka Source Routing) is a very powerful technique
which potentially can be useful for a variety of purposes. However,
with pure datagram routing the overhead of carrying a complete
explicit route with each packet is prohibitive. However, MPLS allows
the explicit route to be carried only at the time that the label
switched path is set up, and not with each packet. This implies that
MPLS makes explicit routing practical. This in turn implies that MPLS
can make possible a number of advanced routing features which depend
upon explicit routing.
1.5.1.3 Traffic Engineering
Traffic engineering refers to the process of selecting the paths
chosen by data traffic in order to balance the traffic load on the
various links, routers, and switches in the network. Traffic
engineering is most important in networks where multiple parallel or
alternate paths are available. The rapid growth in the Internet, and
particularly the associated rapid growth in the demand for bandwidth,
has tended to cause some core networks to become increasingly
"branchy" in recent years, resulting in an increase in the importance
of traffic engineering.
It is common today, in networks that are running IP over an ATM core
using PVCs, to manually configure the path of each PVC in order to
equalize the traffic levels on different links in the network. Thus
traffic engineering is typically done today in IP over ATM networks
using manual configuration.
Traffic engineering is difficult to accomplish with datagram routing.
Some degree of load balancing can be obtained by adjusting the
metrics associated with network links. However, there is a limit to
how much can be accomplished in this way, and in networks with a
large number of alternative paths between any two points balancing of
the traffic levels on all links is difficult to achieve solely by
adjustment of the metrics used with hop by hop datagram routing.
MPLS allows streams from any particular ingress node to any
particular egress node to be individually identified. MPLS therefore
provides a straightforward mechanism to measure the traffic
associated with each ingress node to egress node pair. In addition,
since MPLS allows efficient explicit routing of Label Switched Paths,
it is straightforward to ensure that any particular stream of data
takes the preferred path.
The hard part of traffic engineering is selection of the method used
to route each Label Switched Path. There are a variety of possible
ways to do this, ranging from manual configuration of routes, to use
of a routing protocol which announces traffic loads in the network
combined with background recomputation of paths.
1.5.1.4 QoS Routing
QoS routing refers to a method of routing in which the route chosen
for a particular stream is chosen in response to the QoS required for
that stream. In many cases QoS routing needs to make use of explicit
routing for several reasons:
In some cases specific bandwidth is likely to be reserved for each of
many specific streams of data. This implies that the total bandwidth
of multiple streams may exceed the bandwidth available on any
particular link, and thus not all streams, even between the same
ingress and egress nodes, can take the same path. Instead, individual
streams will need to be individually routed. This is somewhat
analogous to traffic engineering, but might require separation of
streams on a finer granularity. Thus explicit routing may be needed
in order to allow each stream to be individually routed, and to
eliminate the need for each switch along the path of a stream to
compute the route for each stream.
Consider the case of routing a stream with a specific bandwidth
requirement: In this case the route chosen will depend upon the
amount of bandwidth which is requested. For any one given bandwidth
it is straightforward to select a path. However there are a lot of
different levels of bandwidth which could in principle be requested.
This makes it impractical to precompute all possible paths for all
possible bandwidths. If the path for a particular stream must be
computed on demand, then it is undesirable to require every LSR on
the path to compute the path. Instead, it is preferable to have the
first node compute the path and specify the route to be followed
through use of an explicit route.
For a variety of reasons the information available for QoS routing
may in some cases be slightly out of date. This implies that the
attempt to select a specific path for a QoS-sensitive stream may in
some cases fail, due to a particular node or link not having the
required resources available. In these cases it is not in general
always feasible to tell all other nodes in the network of the limited
resource in one particular network element. If explicit routing is
available, then this permits the initial node of the stream (the
ingress node in MPLS) to be informed that the indicated network
element is not able to carry the stream, allowing an alternate path
to be selected. However, in this case the node that selects the
alternate path has to use explicit routing in order to force the
stream to follow the alternate path.
These and similar examples implies that explicit routing is necessary
in order to do an adequate job of QoS routing. Given that MPLS allows
efficient explicit routing, it follows that MPLS also facilitates QoS
routing.
1.5.1.5 Complex Mappings from IP Packet to Forwarding Equivalence Class
MPLS allows the mapping from IP packet to forwarding equivalence
class to be performed only once, at the ingress to an MPLS area. This
facilitates complex mappings from IP packet to FEC than would
otherwise be impractical.
For example, consider the case of provisioned QoS: Some ISPs offer a
service wherein specific customers subscribe to received
differentiated services (e.g., their packets may receive preferential
forwarding treatment). Mapping of IP packets to the service level may
require knowing the customer who is transmitting the packet, which
may in turn require packet filtering based on source and destination
address, incoming interface, and other characteristics. The sheer
number of filters that are needed in a moderate sized ISP preclude
repetition of the filters at every router throughout the network.
Also, some information such as incoming interface is not available
except at the ingress node to the network. This implies that the
preferred way to offer provisioned QoS is to map the packet at the
ingress point to the preferred QoS level, and then label the packet
in some way. MPLS offers an efficient method to label the QoS class
associated with any particular packet.
Other examples of complex mappings from IP packet to FEC are also
likely to be determined as MPLS is deployed.
1.5.1.6 Partitioning of Functionality
Due to the support of the different label granularities, it will be
possible to hierarchically partition the processing functionality to
the different network elements, so that the more heavy processing
takes place on the edges of the network, near the customers, and on
the core network the processing is as simple as possible, e.g. pure
label based forwarding.
AS level aggregations will enable building of the fully switched
backbone networks and traffic exchange points. Also, it will be
possible for operators to fully switch the transit traffic traveling
through the operator’s network. Deaggregation will be needed for the
streams that are destined in the networks connected to the MPLS
domain, but it shall be noted that this deaggregation will only need
to perform lookup operations associated with finding the label for
egress router or interface, e.g. TOS information bound to label in
source is still valid, and can be honored on basis of which label the
packet was received in. It shall be noted that it is even impossible
for the receiving domain to do the classification as the original
packet classification policy is not known by the receiving domain.
As one example of the improved functional partitioning, consider the
case of the use of packet filters to map IP packets into a
substantial number of queues, such that each queue receives
differentiated services. For example, suppose that a network supports
individual queuing for on the order of 100 different customers, with
packets mapped to queues based on the source and destination IP
address. In this case, with MPLS the packet filtering can be done
solely on the edge of the network, with the packets mapped to labels
such that each individual user receives separate labels. Thus with
MPLS the filtering can be performed at the edge only of the network.
This allows complex mappings of IP packets to forwarding equivalence
class.
1.5.1.7 Single Forwarding Paradigm with Service Level Differentiation
MPLS can allow a single forwarding paradigm to be used to support
multiple types of service on the same network.
Because of the forwarding paradigm, it will be possible to carry the
different services through the same network elements, regardless of
the control plane protocols used for the population of the LSR’s LIB.
It is for example possible, in case of ATM based switching system to
support all the native ATM services, frame relay services, and
labeled IP services. The simultaneous support of multiple service may
need partitioning of the label space between the services, and shall
be supported by the label distribution / management protocol.
Non-exhaustive list of examples of the services suitable for carrying
over LSRs are IP traffic, Frame Relay traffic, ATM traffic (in case
of cell switching), IP tunneling, VPNs, and other datagram protocols.
Note that MPLS does not necessarily use the same header format over
all types of media. However, over any particular type of media a
single header format (at least for the lowest level of the Label
Stack) should be possible.
1.5.2 Benefits Relative to Use of an ATM or Frame Relay Core
Note: This section compares MPLS with other methods for
interconnecting routers over a switched core network. We are not
considering methods for interconnecting hosts located on virtual
networks. For example the ATM Forum LANE and MPOA standards support
virtual networks. MPLS does not directly support virtual networks,
and should not be compared directly with MPOA or LANE.
Previously available methods for interconnecting routers in an IP
over ATM environment make use of either: (i) a full mesh 'n-squared'
overlay of virtual circuits between n ATM-attached routers; (ii) A
partial mesh of VCs between routers; or (iii) A partial mesh of VCs,
plus the use of NHRP to facilitate on demand cut-through SVCs.
1.5.2.1 Scaling of the Routing Protocol
Relative to the interconnection of IP over an ATM core, MPLS improves
the scaling of routing due to reduced number of peers and elimination
of the 'n-squared' logical links between routers used to operate the
routing protocols.
Because all LSRs will run standard routing protocols, the number of
the peers routers need to communicate with are reduced to the number
of the LSRs and router given LSR is directly connected to, instead of
having to peer with large number of routers at the ends of the
switched L2 paths. This benefit is achieved because the edge LSRs do
not need to peer with every other edge LSR in the domain as is case
on hybrid switch / router network.
1.5.2.2 Common Operation over Packet and Cell media
MPLS makes use of common methods for routing and forwarding over
packet and cell media, and potentially allows a common approach to
traffic engineering, QoS routing, and other aspects of operation. For
example, this means that the same method for label distribution can
be used over Frame Relay and ATM media, as well as between LSRs using
the MPLS Shim Header for forwarding over other media (such as PPP
links and broadcast LANs).
Note: There may be some differences with respect to the operation of
different media. For example, if VP merge is used with ATM media
(rather than VC merge) then the merge operation may be somewhat
different than what it would be with packet media or with ATM using
VC merge.
1.5.2.3 Easier Management
The use of a common method for label distribution and common routing
protocols over multiple types of media is expected to simplify
network management of MPLS networks.
1.5.2.4 Elimination of the 'Routing over Large Clouds' Issue
MPLS eliminates the need to use NHRP and on-demand cut-through SVCs
for operation over ATM. This eliminates the latency problem
associated with cut-through SVCs.
2. Discussion of Core MPLS Components 2. Discussion of Core MPLS Components
2.1 The Basic Routing Approach 2.1 The Basic Routing Approach
Routing is accomplished through the use of standard L3 routing Routing is accomplished through the use of standard L3 routing
protocols, such as OSPF and BGP. The information maintained by the protocols, such as OSPF and BGP. The information maintained by the
L3 routing protocols is then used to distribute labels to neighboring L3 routing protocols is then used to distribute labels to neighboring
nodes that are used in the forwarding of packets as described below. nodes that are used in the forwarding of packets as described below.
In the case of ATM networks, the labels that are distributed are In the case of ATM networks, the labels that are distributed are
VPI/VCIs and a separate protocol (i.e., PNNI) is not necessary for VPI/VCIs and a separate protocol (i.e., PNNI) is not necessary for
the establishment of VCs for IP forwarding. the establishment of VCs for IP forwarding.
The topological scope of a routing protocol (i.e. routing domain) and The topological scope of a routing protocol (i.e. routing domain) and
the scope of label switching MPLS-capable nodes may be different. the scope of label switching MPLS-capable nodes may be different.
For example, MPLS-knowledgeable and MPLS-ignorant nodes, all of which For example, MPLS-knowledgeable and MPLS-ignorant nodes, all of which
are OSPF routers, may be co-resident in an area. In the case that are OSPF routers, may be co-resident in an area. In the case that
neighboring routers know MPLS, labels can be exchanged and used. neighboring routers know MPLS, labels can be exchanged and used.
skipping to change at page 11, line 43 skipping to change at page 18, line 7
being the closest to pure datagram forwarding. However this approach being the closest to pure datagram forwarding. However this approach
(like pure datagram forwarding) has the disadvantage that when a (like pure datagram forwarding) has the disadvantage that when a
packet is forwarded it is not known whether the packet is being packet is forwarded it is not known whether the packet is being
forwarded into a loop, into a black hole, or towards links which have forwarded into a loop, into a black hole, or towards links which have
inadequate resources to handle the traffic flow. These disadvantages inadequate resources to handle the traffic flow. These disadvantages
are necessary with pure datagram forwarding, but are optional design are necessary with pure datagram forwarding, but are optional design
choices to be made when label switching is being used. choices to be made when label switching is being used.
There are cases where it would be desirable to have additional There are cases where it would be desirable to have additional
knowledge implicit in the existence of the label. For example, one knowledge implicit in the existence of the label. For example, one
approach to avoiding loops (see section x.x below) involves signaling approach to avoiding loops (see section 4.3) involves signaling the
the label distribution along a path before packets are forwarded on label distribution along a path before packets are forwarded on that
that path. With this approach the fact that a node has a label to use path. With this approach the fact that a node has a label to use for
for a particular IP packet would imply the knowledge that following a particular IP packet would imply the knowledge that following the
the label (including label swapping at subsequent nodes) leads to a label (including label swapping at subsequent nodes) leads to a non-
non-looping path which makes progress towards the destination looping path which makes progress towards the destination (something
(something which is usually, but not necessarily always true when which is usually, but not necessarily always true when using pure
using pure datagram routing). This would of course require some sort datagram routing). This would of course require some sort of label
of label distribution/setup protocol which signals along the path distribution/setup protocol which signals along the path being setup
being setup before the labels are available for packet forwarding. before the labels are available for packet forwarding. However, there
are also other consequences to having additional semantics associated
However, there are also other consequences to having additional with the label: specifically, procedures are needed to ensure that
semantics associated with the label: specifically, procedures are the semantics are correct. For example, if the fact that you have a
needed to ensure that the semantics are correct. For example, if the label for a particular destination implies that there is a loop-free
fact that you have a label for a particular destination implies that path, then when the path changes some procedures are required to
there is a loop-free path, then when the path changes some procedures ensure that it is still loop free. Another example of semantics which
are required to ensure that it is still loop free. Another example of could be implicit in a label is the identity of the higher level
semantics which could be implicit in a label is the identity of the protocol type which is encoded using that label value.
higher level protocol type which is encoded using that label value.
In either case, the specific value of a label to use for a stream is In either case, the specific value of a label to use for a stream is
strictly a local issue; however the decision about whether to use the strictly a local issue; however the decision about whether to use the
label may be based on some global (or at least wider scope) knowledge label may be based on some global (or at least wider scope) knowledge
that, for example, the label-switched path is loop-free and/or has that, for example, the label-switched path is loop-free and/or has
the appropriate resources. the appropriate resources.
A similar example occurs in ATM networks: With standard ATM a A similar example occurs in ATM networks: With standard ATM a
signaling protocol is used which both reserves resources in switches signaling protocol is used which both reserves resources in switches
along the path, and which ensures that the path is loop-free and along the path, and which ensures that the path is loop-free and
terminates at the correct node. Thus implicit in the fact that an ATM terminates at the correct node. Thus implicit in the fact that an ATM
node has a VPI/VCI for forwarding a particular piece of data is the node has a VPI/VCI for forwarding a particular piece of data is the
knowledge that the path has been set up successfully. knowledge that the path has been set up successfully.
Another similar examples occurs with multipoint to point trees over Another similar examples occurs with multipoint to point trees over
ATM (see section xx below), where the multipoint to point tree uses a ATM (see section 4.2 below), where the multipoint to point tree uses
VP, and cell interleave at merge points in the tree is handled by a VP, and cell interleave at merge points in the tree is handled by
giving each source on the tree a distinct VCI within the VP. In this giving each source on the tree a distinct VCI within the VP. In this
case, the fact that each source has a known VPI/VCI to use needs to case, the fact that each source has a known VPI/VCI to use needs to
(implicitly or explicitly) imply the knowledge that the VCI assigned (implicitly or explicitly) imply the knowledge that the VCI assigned
to that source is unique within the context of the VP. to that source is unique within the context of the VP.
In general labels are used to optimize how the system works, not to In general labels are used to optimize how the system works, not to
control how the system works. For example, the routing protocol control how the system works. For example, the routing protocol
determines the path that a packet follows. The presence or absence of determines the path that a packet follows. The presence or absence of
a label assignment should not effect the path of a L3 packet. Note a label assignment should not effect the path of a L3 packet. Note
however that the use of labels may make capabilities such as explicit however that the use of labels may make capabilities such as explicit
skipping to change at page 14, line 9 skipping to change at page 20, line 20
is, it could be associated with some combination of source and is, it could be associated with some combination of source and
destination address or other information within the packet. This destination address or other information within the packet. This
might for example be done on an administrative basis to aid in might for example be done on an administrative basis to aid in
effecting policy. A label could also correspond to all packets which effecting policy. A label could also correspond to all packets which
match a particular Integrated Services filter specification. match a particular Integrated Services filter specification.
Labels can also represent explicit routes. This use is semantically Labels can also represent explicit routes. This use is semantically
equivalent to using an IP tunnel with a complete explicit route. This equivalent to using an IP tunnel with a complete explicit route. This
is discussed in more detail in section 4.10. is discussed in more detail in section 4.10.
2.2.3 Label Assignment 2.2.2.1 Examples of Unicast traffic granularities:
- PQ (Port Quadruples) same IP source address prefix, destination
address prefix, TTL, IP protocol and TCP/UDP source/destination ports
- PQT (Port Quadruples with TOS) same IP source address prefix,
destination address prefix, TTL, IP protocol and TCP/UDP
source/destination ports and same IP header TOS field (including
Precedence and TOS bits).
- HP (Host Pairs) Same specific IP source and destination address
(32 bit)
- NP (Network Pairs) Same IP source and destination address prefixes
(variable length)
- DN (Destination Network) Same IP destination network address
prefix (variable length)
- ER (Egress Router) Same egress router ID (e.g. OSPF)
- NAS (Next-hop AS) Same next-hop AS number (BGP)
- DAS (Destination AS) Same destination AS number (BGP)
2.2.2.2 Multicast traffic granularities:
- SST (Source Specific Tree) Same source address and multicast group
- SMT (Shared Multicast Tree) Same multicast group address
2.2.3 Label Assignment
Essential to label switching is the notion of binding between a label Essential to label switching is the notion of binding between a label
and Network Layer routing (routes). A control component is and Network Layer routing (routes). A control component is
responsible for creating label bindings, and then distributing the responsible for creating label bindings, and then distributing the
label binding information among label switches. Label assignment label binding information among label switches. Label assignment
involves allocating a label, and then binding a label to a route. involves allocating a label, and then binding a label to a route.
Label assignment can be driven by control traffic or by data traffic. Label assignment can be driven by control traffic or by data traffic.
This is discussed in more detail in section 3.4. This is discussed in more detail in section 3.4.
Control traffic driven label assignment has several advantages, as Control traffic driven label assignment has several advantages, as
skipping to change at page 27, line 44 skipping to change at page 34, line 36
highly preferable to define, implement, and deploy a new tool, and to highly preferable to define, implement, and deploy a new tool, and to
determine through experience that the new tool is sufficient, before determine through experience that the new tool is sufficient, before
breaking a tool which is as widely used as traceroute. breaking a tool which is as widely used as traceroute.
Methods that may be used to either allow traceroute to be used in an Methods that may be used to either allow traceroute to be used in an
MPLS network, or to replace traceroute, are discussed in section MPLS network, or to replace traceroute, are discussed in section
4.14. 4.14.
4. Technical Approaches 4. Technical Approaches
We believe that section 4 is probably less complete than other
sections. Additional subsections are likely to be needed as a result
of additional discussions in the MPLS working group.
4.1 Label Distribution 4.1 Label Distribution
A fundamental requirement in MPLS is that an LSR forwarding label A fundamental requirement in MPLS is that an LSR forwarding label
switched traffic to another LSR apply a label to that traffic which switched traffic to another LSR apply a label to that traffic which
is meaningful to the other (receiving the traffic) LSR. LSR's could is meaningful to the other (receiving the traffic) LSR. LSR's could
learn about each other's labels in a variety of ways. We call the learn about each other's labels in a variety of ways. We call the
general topic "label distribution". general topic "label distribution".
4.1.1 Explicit Label Distribution 4.1.1 Explicit Label Distribution
skipping to change at page 31, line 42 skipping to change at page 38, line 24
variety of environments with a wide variety of equipment, this variety of environments with a wide variety of equipment, this
implies that it is important for any LDP developed by the MPLS WG to implies that it is important for any LDP developed by the MPLS WG to
ensure reliable delivery of label information. ensure reliable delivery of label information.
Reliable delivery of LDP packets may potentially be accomplished Reliable delivery of LDP packets may potentially be accomplished
either by using an existing reliable transport protocol such as TCP, either by using an existing reliable transport protocol such as TCP,
or by specifying reliability mechanisms as part of LDP (for example, or by specifying reliability mechanisms as part of LDP (for example,
the reliability mechanisms which are defined in IDRP could the reliability mechanisms which are defined in IDRP could
potentially be "borrowed" for use with LSP). potentially be "borrowed" for use with LSP).
TCP supports flow control {in addition to supporting reliable
delivery of data). Flow control is a desirable feature which will be
useful for MPLS (as well as other applications making use of a
reliable transport) and therefore needs to be built into whatever
reliability mechanism is used for MPLS.
4.1.5 Label Purge Mechanisms 4.1.5 Label Purge Mechanisms
Another issue to be considered is the "lifetime" of label data once Another issue to be considered is the "lifetime" of label data once
it arrives at an LSR, and the method of purging label data. There are it arrives at an LSR, and the method of purging label data. There are
several methods that could be used either separately, or (more several methods that could be used either separately, or (more
likely) in combination. likely) in combination.
One approach is for label information to be timed out. With this One approach is for label information to be timed out. With this
approach a lifetime is distributed along with the label value. The approach a lifetime is distributed along with the label value. The
label value may be refreshed prior to timing out. If the label is not label value may be refreshed prior to timing out. If the label is not
skipping to change at page 32, line 32 skipping to change at page 39, line 20
An alternative method for invalidating labels is to make use of an An alternative method for invalidating labels is to make use of an
explicit label removal message. explicit label removal message.
4.2 Stream Merging 4.2 Stream Merging
In order to scale O(n) (rather than O(n-squared), MPLS makes use of In order to scale O(n) (rather than O(n-squared), MPLS makes use of
the concept of stream merge. This makes use of multipoint to point the concept of stream merge. This makes use of multipoint to point
streams in order to allow multiple streams to be merged into one streams in order to allow multiple streams to be merged into one
stream. stream.
Types of Stream Merge: 4.2.1 Types of Stream Merge:
There are several types of stream merge that can be used, depending There are several types of stream merge that can be used, depending
upon the underlying media. upon the underlying media.
When MPLS is used over frame based media merging is straightforward. When MPLS is used over frame based media merging is straightforward.
All that is required for stream merge to take place is for a node to All that is required for stream merge to take place is for a node to
allow multiple upstream labels to be forwarded the same way and allow multiple upstream labels to be forwarded the same way and
mapped into a single downstream label. This is referred to as frame mapped into a single downstream label. This is referred to as frame
merge. merge.
skipping to change at page 33, line 41 skipping to change at page 40, line 28
frame be received before any cells corresponding to that frame be frame be received before any cells corresponding to that frame be
forwarded. VC merge therefore requires capabilities which are forwarded. VC merge therefore requires capabilities which are
generally not available in most existing ATM forwarding hardware. generally not available in most existing ATM forwarding hardware.
The alternative for use over ATM media is VP merge. Here multiple VPs The alternative for use over ATM media is VP merge. Here multiple VPs
can be merged into a single VP. Separate VCIs within the merged VP can be merged into a single VP. Separate VCIs within the merged VP
are used to distinguish frames (e.g., IP packets) from different are used to distinguish frames (e.g., IP packets) from different
sources. In some cases, one VP may be used for the tree from each sources. In some cases, one VP may be used for the tree from each
ingress node to a single egress node. ingress node to a single egress node.
Interoperation of Merge Options: 4.2.2 Interoperation of Merge Options:
If some nodes support stream merge, and some nodes do not, then it is If some nodes support stream merge, and some nodes do not, then it is
necessary to ensure that the two types of nodes can interoperate necessary to ensure that the two types of nodes can interoperate
within a single network. This affects the number of labels that a within a single network. This affects the number of labels that a
node needs to send to a neighbor. An upstream LSR which supports node needs to send to a neighbor. An upstream LSR which supports
Stream Merge needs to be sent only one label per forwarding Stream Merge needs to be sent only one label per forwarding
equivalence class (FEC). An upstream neighbor which does not support equivalence class (FEC). An upstream neighbor which does not support
Stream Merge needs to be sent multiple labels per FEC. However, there Stream Merge needs to be sent multiple labels per FEC. However, there
is no way of knowing a priori how many labels it needs. This will is no way of knowing a priori how many labels it needs. This will
depend on how many LSRs are upstream of it with respect to the FEC in depend on how many LSRs are upstream of it with respect to the FEC in
skipping to change at page 35, line 20 skipping to change at page 42, line 6
request one VP. VC merge node would request only a single VPI/VCI request one VP. VC merge node would request only a single VPI/VCI
(since they can merge all upstream traffic into a single VC). Non- (since they can merge all upstream traffic into a single VC). Non-
merge nodes would pass on any requests that they get from above, plus merge nodes would pass on any requests that they get from above, plus
request a VPI/VCI for traffic that they originate (if they can be request a VPI/VCI for traffic that they originate (if they can be
ingress nodes). However, non-merge nodes which can only do VC ingress nodes). However, non-merge nodes which can only do VC
forwarding (and not VP forwarding) will need to know which VCIs are forwarding (and not VP forwarding) will need to know which VCIs are
used within each VP in order to install the correct VCs in its used within each VP in order to install the correct VCs in its
forwarding table. A detailed description of how this could work is forwarding table. A detailed description of how this could work is
FFS. FFS.
Coordination of the VCI space with VP Merge: 4.2.3 Coordination of the VCI space with VP Merge:
VP merge requires that the VCIs be coordinated to ensure uniqueness. VP merge requires that the VCIs be coordinated to ensure uniqueness.
There are a number of ways in which this may be accomplished: There are a number of ways in which this may be accomplished:
1. Each node may be pre-configured with a unique VCI value (or 1. Each node may be pre-configured with a unique VCI value (or
values). values).
2. Some one node (most likely they root of the multipoint to point 2. Some one node (most likely they root of the multipoint to point
tree) may coordinate the VCI values used within the VP. A tree) may coordinate the VCI values used within the VP. A
protocol mechanism will be needed to allow this to occur. How protocol mechanism will be needed to allow this to occur. How
skipping to change at page 35, line 49 skipping to change at page 42, line 35
3. Other unique information such as portions of a class B or class 3. Other unique information such as portions of a class B or class
C address may be used to provide a unique VCI value. C address may be used to provide a unique VCI value.
4. Another alternative is to implement a simple hardware extension 4. Another alternative is to implement a simple hardware extension
in the ATM switches to keep the VCI values unique by dynamically in the ATM switches to keep the VCI values unique by dynamically
altering them to avoid collision. altering them to avoid collision.
VP merge makes less efficient use of the VPI/VCI space (relative to VP merge makes less efficient use of the VPI/VCI space (relative to
VC merge). When VP merge is used, the LSPs may not be able to VC merge). When VP merge is used, the LSPs may not be able to
transit public ATM networks that dont support SVP. transit public ATM networks that don't support SVP.
Buffering Issues Related To Stream Merge: 4.2.4 Buffering Issues Related To Stream Merge:
There is an issue regarding the amount of buffering required for There is an issue regarding the amount of buffering required for
frame merge, VC merge, and VP merge. Frame merge and VC merge frame merge, VC merge, and VP merge. Frame merge and VC merge
requires that intermediate points buffer incoming packets until the requires that intermediate points buffer incoming packets until the
entire packet arrives. This is essentially the same as is required in entire packet arrives. This is essentially the same as is required in
traditional IP routers. traditional IP routers.
VP merge allows cells to be transmitted by intermediate nodes as soon VP merge allows cells to be transmitted by intermediate nodes as soon
as they arrive, reducing the buffering and latency at intermediate as they arrive, reducing the buffering and latency at intermediate
nodes. However, the use of VP merge implies that cells from multiple nodes. However, the use of VP merge implies that cells from multiple
skipping to change at page 36, line 30 skipping to change at page 43, line 14
implying that increase in buffers required for some purpose (egress implying that increase in buffers required for some purpose (egress
traffic) will be offset by a reduction in buffers required for other traffic) will be offset by a reduction in buffers required for other
purposes (transit traffic). Also, routers today typically deal with purposes (transit traffic). Also, routers today typically deal with
high-fanout channelized interfaces and with multi-VC ATM interfaces, high-fanout channelized interfaces and with multi-VC ATM interfaces,
implying that the requirement of buffering simultaneously arriving implying that the requirement of buffering simultaneously arriving
cells from multiple packets and sources is something that routers cells from multiple packets and sources is something that routers
typically do today. This is not meant to imply that the required typically do today. This is not meant to imply that the required
buffer size and performance is inexpensive, but rather is meant to buffer size and performance is inexpensive, but rather is meant to
observe that it is a solvable issue. observe that it is a solvable issue.
ATM equipment provides traffic shaping, in which the ATM cells
associated with any one particular VC are intentionally not
transmitted back to back, but rather are spread out over time in
order to place less short term buffering load on switches. Since VC
merge requires that all cells associated with a particular packet (or
a particular AAL5 frame) are buffered before any cell from the packet
can be transmitted, VC merge defeats much of the intent of traffic
shaping. An advantage of VP merge is that it preserves traffic
shaping through ATM switches acting as LSRs. While traffic shaping
may generally be expected to reduce the buffering requirements in ATM
switches (whether acting as MPLS switches or as native ATM switches),
the precise effect of traffic shaping has not been studied in the
context of MPLS.
4.3 Loop Handling 4.3 Loop Handling
Generally, methods for dealing with loops can be split into three Generally, methods for dealing with loops can be split into three
categories: Loop Survival makes use of methods which minimize the categories: Loop Survival makes use of methods which minimize the
impact of loops, for example by limiting the amount of network impact of loops, for example by limiting the amount of network
resources which can be consumed by a loop; Loop Detection allows resources which can be consumed by a loop; Loop Detection allows
loops to be set up, but later detects these loops and eliminates loops to be set up, but later detects these loops and eliminates
them; Loop Prevention provides methods for avoiding setting up L2 them; Loop Prevention provides methods for avoiding setting up L2
forwarding in a way which results in a L2 loop. forwarding in a way which results in a L2 loop.
skipping to change at page 42, line 30 skipping to change at page 49, line 29
over the VC must be at a fine enough granularity to be label switched over the VC must be at a fine enough granularity to be label switched
through receiving domain. One potential place where the two through receiving domain. One potential place where the two
technologies might come into play is in moving data from one campus technologies might come into play is in moving data from one campus
via the wide-area to another campus. In such a scenario, the two via the wide-area to another campus. In such a scenario, the two
technologies would border precisely at the point where summarization technologies would border precisely at the point where summarization
is likely to occur. Each campus would have a detailed understanding is likely to occur. Each campus would have a detailed understanding
of itself, but not of the other campus. The wide-area is likely to of itself, but not of the other campus. The wide-area is likely to
have summarized knowledge only. But at such a point level 3 have summarized knowledge only. But at such a point level 3
processing becomes the likely solution. processing becomes the likely solution.
4.5 Operation in a Hierarchy 4.5. Operation in a hierarchy
This section is FFS. MPLS allows hierarchical operation, through use of a label stack.
This allows MPLS to simultaneously be used for routing at a fine
grain level (for example, between individual routers within an ISP)
and at a higher "area by area" or "domain by domain" level.
4.6 Stacked Labels in a Flat Routing Environment 4.5.1 Example of Hierarchical Operation
This section is FFS. Figure 1 illustrates an example of how MPLS may operate in a
hierarchy. This example illustrates three transit routing domains
(Domain #1, #2, and #3). For example, these three domains may
represent internet service providers. Domain Boundary Routers are
illustrated in each domain (routers R1 and R2 in domain #1, routers
R3 and R8 in domain #2, and routers R9 and R10 in domain #3. Suppose
that these domain boundary routers are operating BGP.
Internal routers are not illustrated in domains 1 and 3. However,
internal routers are illustrated within domain #2. In particular, the
path between routers R3 and R8 follows the internal routers R4, R5,
R6, and R7 within domain #2.
................. ........................ ................
. . . . . .
. . . . . .
.R1 R2-------R3 R8-------R9 R10.
. . . \ / . . .
. . . R4---R5---R6---R7 . . .
. . . . . .
. Domain#1 . . Domain#2 . . Domain#3 .
................. ........................ ................
Example of the Use of MPLS in a Hierarchy
In this example there are two levels of routing taking place. For
example, OSPF may be used for routing within Domain #2. In this case
the routers R3, R4, R5, R6, R7, and R8 may be running OSPF amongst
themselves in order to compute routes within Domain #2. The domain
boundary routers (R1, R2, R3, R8, R9, and R10) operate BGP in order
to determine paths between routing domains.
MPLS allows label forwarding to be done independently at multiple
levels. In this example, MPLS may be used at the BGP level (between
routers R1, R2, R3, R8, R9, and R10) and at the OSPF level (between
routers R4, R5, R6, and R7). Thus when the IP packet traverses Domain
number 2, it will contain two labels, encoded as a "label stack". The
higher level label would be used between routers R3 and R8. This
would be encapsulated inside a header specifying a lower level label
used within domain 2.
Consider the forwarding operation that takes place at router R3. In
this case, R3 will receive a packet from R2 containing a single label
(the BGP level label). R3 will need to swap BGP level labels in order
to put the label that R8 expects. R3 will also need to add an OSPF-
level label, as is expected by R4. R3 therefore "pushes down" the BGP
level label in the label stack, by adding a lower level label. Also
note that the actual label swapping operation performed by R3 can be
optimized to allow very simple forwarding: R3 receives a single
incoming label from R2, and can map this label into the new label
header to be prepended to the packet, it just happens that the new
label header to be added by R3 contains two labels rather than one.
4.5.2 Components Required for Hierarchical Operation
In order for MPLS to operate in a hierarchy, there are three things
which must be accomplished:
- Hierarchical Label Exchange in LDP
The Label Distribution Protocol needs to exchange labels at each
level of the hierarchy. In our example, R3 needs to exchange label
bindings with R8 for operation at the BGP level. At the same time,
R3 needs to exchange label bindings with R4 (and R4 needs to
exchange label bindings with R5) for operation at the OSPF level.
The control component for hierarchical labeling is essentially the
same as that for single level tagging, except that labels are
exchanged not just among physically adjacent LSRs but between those
switching on the same level in the tag stack.
- Label Stack
Multiple labels need to be carried in data packets. For example,
when a data packet is being carried across domain #2, the data
packet needs to be encapsulated in a header which carries BGP level
label, and the resulting packet needs to be carried in a header
which carries an OSPF level label.
- Configuration
It is necessary for routers to know when hierarchical label
switching is being used.
4.5.3 Some Restrictions on Use of Hierarchical MPLS
Consider the example in figure 1. In this case, the BGP-level label is
encoded by router R1. Label swapping is employed for packet forwarding
at R2, R3, R8, and R9. This is only possible if R1 knows the right label
to use, implying that the granularity used in mapping packets to
forwarding equivalence classes is the same at routers R2, R3, R8, and
R9.
We can consider some specific examples to illustrate the issue:
Suppose that the destination host is within domain 3. In this case, it
is very likely that router R9 will forward the packet based on a finer
grain than was used previously. For example, a relatively short address
prefix may be used for advertising the addresses reachable in domain 3,
while longer (more specific) address prefixes may be used for specific
areas or subnets within domain 3. In this case router R1 may assign a
BGP level label to the packet, and label based forwarding at the BGP
level may be used by routers R1, R2, R3, and R8. However, router R9 will
need to make use of layer 3 forwarding.
Alternatively, suppose that domain 3 is an Internet Service Provider,
which offers service to multiple routing domains. Suppose that in this
case domain 3 makes use of a single CIDR address block (based on a
single address prefix), with smaller address blocks (corresponding to
longer address prefixes) assigned to each of multiple domains who get
their Internet service from domain 3. Suppose that the destination for a
particular IP packet is contained in one of these smaller domains whose
addresses are contained in the larger address block assigned to and
administered by domain 3. Again in this case router R9 will need to make
use of label based forwarding.
Let's consider another possible complication: Suppose that router R1 is
an MPLS node, but that some of the internal routers within domain 1 do
not know about MPLS. In this case, suppose that R1 encapsulates an IP
packet in an MPLS header in order to carry the BGP level label. In this
case the non-MPLS-capable routers within domain 1 will not know what to
do with the MPLS header. This implies that MPLS can be used at a higher
level (such as between the border routers R1 and R2 in our example) only
if either the lower level routers (such as the routers within domain 1)
are also using MPLS, or the MPLS header is itself encapsulated within an
IP header for transmission across the domain.
These examples imply that there are some cases where IP forwarding will
be required in a hierarchy. While hierarchical MPLS may be useful in
many cases, it does not replace layer 3 forwarding.
4.5.4 The Relationship between MPLS hierarchy and Routing Hierarchy
4.5.4.1 Stacked Labels in a Flat Routing Environment
The label stacking mechanism can be useful in some scenarios independent
of routing hierarchy.
The basic concept of stacking is to provide a mechanism to segregate
streams within a switched path. Under normal operation, when packets
are encapsulated into a single L2 header, if multiple streams are
forwarded into a switched path, it will require L3 processing to
segregate a certain stream at the end of the switched path. The
stacking mechanism provides an easy way to maintain the identity of
various streams which are merged into a single switched path.
One useful application of this technique is in Virtual Private Networks.
The packets can be switched both at the ingress and egress nodes of the
provider network. A packet coming in at one end of a customer network
contains an encapsulated header with the VPN label. At the VPN ingress
node, the header is "popped", to provide the label for switching through
the VPN. Further, this header is then "pushed" with an encapsulation of
the far end customer label. At the VPN egress node, the packet header
is "popped" again, and the new header provides the label for switching
through the customer site. This enables one to provide customers with
benefits of VPN with end-to-end switching for optimal performance.
Another interesting use can be in conjunction with RSVP flows. In RSVP,
senders flows can be logically merged under a single resource
reservation using the Shared and the Wildcard filters. The stacking
mechanism can be used to merge flows into a single label and the shared
QoS can be applied to the single label on top of the stack. Since
sender flows within the merged switched path maintain their identity, it
is easy to demerge at a downstream node without requiring L3 processing
of the packets. Another similar application can be merging of several
premium service flows with similar QoS into a single switched path. This
helps in conserving labels in backbone of a large networks.
Yet another useful application can be DVMRP tunnels similar in concept
to the DVMRP tunnels used in the existing Mbone. The ingress node to
the DVMRP switched tunnels encapsulates the label learned from the
egress node of the DVMRP tunnel for a particular (S,G) pair before
forwarding packets into the DVMRP tunnel. The egress node of the tunnel
just pops the top label and switches the packet based on the interior
label.
Note that the use of tunnels can be also quite beneficial in a non-
hierarchical environment. Take for example the case where a domain
contains a subset of MPLS nodes. The MPLS egress can advertise labels
for the routes which are within the domain, but are external to the MPLS
core. The ingress node can encapsulate packets for these destinations
within the header for the aggregated switched path that crosses the MPLS
domain.
It is not evident if this technique has any useful application in a flat
routing domain, but can be used in conjunction with explicit routing
when providing specialized services. The multiple levels of
encapsulation can also be used like loose source routing.
4.5.4.2 Flat labels in a Hierarchical Routing Environment
It is also possible in some environments to use a single level of label
in a network using hierarchical routing. This is for example possible in
the case of a two level OSPF network in which the primary purpose of the
network is to support external routes. Specifically, (depending upon the
types of area hierarchy used) OSPF allows external routes to be
advertised throughout an OSPF routing domain, with each external route
associated with the routerID of the router with reachability to the
specific route. This implies that it is possible to set up an LSP to
every router in the routing domain, and then use the LSP for packets
destined to the associated external routes.
4.5.4.3 Configuration of the Hierarchy
The possibility of having a variety of different relationships between
the routing hierarchy and the MPLS hierarchy leads to an obvious
question: How is the relationship between the two hierarchies to be
determined? At first glance it would seem that this generality leads to
a relatively complex configuration issue, and it could be difficult to
ensure consistent configuration of the network.
One possible solution is to have the MPLS hierarchy default to using the
same hierarchy structure as is used for routing, with each area and
domain boundary (as used by routing) also implying an MPLS domain
boundary. This would allow the normal default operation to conform to
the type of operation that we might expect to be used in most
situations, and would allow a common means of interoperation which we
would expect all vendors of MPLS compliant equipment to support.
4.5.5 Some Advantages of Hierarchical MPLS
The use of hierarchical MPLS allows the routers internal to a transit
routing domain to be isolated from the BGP-level routing information. In
our example network, routers R4, R5, R6, and R7 can forward packets
based solely on the lower level label. These internal routers do not
need to know anything at all about higher level IP routing. Note that
this advantage is not available in conventional IP forwarding: If the
internal routers within a routing domain forward IP packets based on the
destination IP address, then the internal routers need to know which
route to use for any particular destination IP address. By combining
hierarchical routing with label stacks MPLS is able to decouple the
exterior and interior protocols. MPLS switches within a domain (interior
switches) need only carry the reachability information for nodes in the
domain. The MPLS border switches for the domain still, of course, carry
the external routes.
Use of hierarchical MPLS also extends the simpler forwarding offered by
MPLS to domain boundary routers.
MPLS places no bound on the number of labels that may be present in a
label stack. In principal this means that MPLS can support multiple
levels of routing hierarchy.
4.6 I Interoperation of MPLS systems with "Conventional" ATM
If we consider the implementation of MPLS on ATM switches we can imagine
several possibilities.
We might remove ATM Forum control plane completely. This the approach
taken by Ipsilon in their IP Switching approach, and allows ATM switches
to operate as MPLS LSRs.
Alternately, we could build a system that supports a "Ships in the
night" (SIN) mode of operation where the ATM Forum and MPLS control
planes both run on the same hardware but are isolated from each other,
i.e. they do not interact. This allows a single device to simultaneously
operate as both an MPLS LSR and an ATM switch.
We feel that the MPLS architecture should allow both of these models. We
note, however, that neither of them addresses the issue of operation of
MPLS over a public ATM network, i.e. over a network that supports
tariffed access to PVCs and ATM Forum SVCs. Because public ATM service
exists and will, presumably, become more pervasive in the future we feel
that another model needs to be included in the architecture and be
supported by the LDP. We call this model the "integrated" model. In
essence it is the same as the SIN model but without the restriction that
the two control planes are isolated. In the integrated model the MPLS
control plane is able to use the ATM control plane to setup SVCs as
needed. An example of this integrated model that allows the coexistence
and interoperation between ATM and MPLS is the CSR proposal from
Toshiba.
Note that there is a distinction relevant to the protocol specification
process between the SIN and the Integrated approach. SIN does not
require specification other than to require that it be transparent to
both the MPLS and ATM control planes (i.e. neither should know of the
others existence). Realisation of SIN on a particular machine is purely
an engineering challenge for the implementors. The Integrated model on
the other hand requires specification of procedures for the use of SVCs
and association of labels with them.
4.7 Multicast 4.7 Multicast
This section is FFS. This section is FFS.
4.8 Multipath 4.8 Multipath
Many IP routing protocols support the notion of equal-cost multipath Many IP routing protocols support the notion of equal-cost multipath
routes, in which a router maintains multiple next hops for one routes, in which a router maintains multiple next hops for one
destination prefix when two or more equal-cost paths to the prefix destination prefix when two or more equal-cost paths to the prefix
exist. There are a few possible approaches for handling multipath exist. There are a few possible approaches for handling multipath with
with MPLS. MPLS.
In this discussion we will use the term "multipath node" to mean a In this discussion we will use the term "multipath node" to mean a node
node which is keeping track of multiple switched paths from itself which is keeping track of multiple switched paths from itself for a
for a single destination. single destination.
The first approach maintains a separate switched path from each The first approach maintains a separate switched path from each ingress
ingress node via one or more multipath nodes to a merge point. This node via one or more multipath nodes to a merge point. This requires
requires MPLS to distinguish the separate switched paths, so that MPLS to distinguish the separate switched paths, so that learning of a
learning of a new switched path is not misinterpreted as a new switched path is not misinterpreted as a replacement of the same
replacement of the same switched path. This also requires an ingress switched path. This also requires an ingress MPLS node be capable of
MPLS node be capable of distributing the traffic among the multiple distributing the traffic among the multiple switched paths. This
switched paths. This approach preserves switching performance, but at approach preserves switching performance, but at a cost of proliferating
a cost of proliferating the number of switched paths. For example, the number of switched paths. For example, each switched path consumes a
each switched path consumes a distinct label. distinct label.
The second approach establishes only one switched path from any one The second approach establishes only one switched path from any one
ingress node to a destination. However, when the paths from two ingress node to a destination. However, when the paths from two
different ingress nodes happen to arrive at the same node, that node different ingress nodes happen to arrive at the same node, that node may
may use different paths for each (implying that the node becomes a use different paths for each (implying that the node becomes a multipath
multipath node). Thus the switched path chosen by the multipath node node). Thus the switched path chosen by the multipath node may assign a
may assign a different downstream path to each incoming stream. This different downstream path to each incoming stream. This conserves
conserves switched paths and maintains switching performance, but switched paths and maintains switching performance, but cannot balance
cannot balance loads across downstream links as well as the other loads across downstream links as well as the other approaches, even if
approaches, even if switched paths are selectively assigned. With switched paths are selectively assigned. With this approach is that the
this approach is that the L2 path may be different from the normal L3 L2 path may be different from the normal L3 path, as traffic that
path, as traffic that otherwise would have taken multiple distinct otherwise would have taken multiple distinct paths is forced onto a
paths is forced onto a single path. single path.
The third approach allows a single stream arriving at a multipath The third approach allows a single stream arriving at a multipath node
node to be split into multiple streams, by using L3 forwarding at the to be split into multiple streams, by using L3 forwarding at the
multipath node. For example, the multipath node might choose to use a multipath node. For example, the multipath node might choose to use a
hash function on the source and destination IP addresses, in order to hash function on the source and destination IP addresses, in order to
avoid misordering packets between any one IP source and destination. avoid misordering packets between any one IP source and destination.
This approach conserves switched paths at the cost of switching This approach conserves switched paths at the cost of switching
performance. performance.
4.9 Host Interactions 4.9 Host Interactions
There are a range of options for host interaction with MPLS: There are a range of options for host interaction with MPLS:
The most straightforward approach is no host involvement. Thus host The most straightforward approach is no host involvement. Thus host
operation may be completely independent of MPLS, rather hosts operate operation may be completely independent of MPLS, rather hosts operate
according to other IP standards. If there is no host involvement then according to other IP standards. If there is no host involvement then
this implies that the first hop requires an L3 lookup. this implies that the first hop requires an L3 lookup.
If the host is ATM attached and doing NHRP, then this would allow the If the host is ATM attached and doing NHRP, then this would allow the
host to set up a Virtual Circuit to a router. However this brings up host to set up a Virtual Circuit to a router. However this brings up a
a range of issues as was discussed in section 4.4 ("interoperation range of issues as was discussed in section 4.4 ("interoperation with
with NHRP"). NHRP").
On the ingress side, it is reasonable to consider having the first On the ingress side, it is reasonable to consider having the first hop
hop LSR provide labels to the hosts, and thus have hosts attach LSR provide labels to the hosts, and thus have hosts attach labels for
labels for packets that they transmit. This could allow the first hop packets that they transmit. This could allow the first hop LSR to avoid
LSR to avoid an L3 lookup. It is reasonable here to have the host an L3 lookup. It is reasonable here to have the host request labels only
request labels only when needed, rather than require the host to when needed, rather than require the host to remember all labels
remember all labels assigned for use in the network. assigned for use in the network.
On the egress side, it is questionable whether hosts should be On the egress side, it is questionable whether hosts should be involved.
involved. For scaling reasons, it would be undesirable to use a For scaling reasons, it would be undesirable to use a different label
different label for reaching each host. for reaching each host.
4.10 Explicit Routing 4.10 Explicit Routing
There are two options for Route Selection: (1) Hop by hop routing, There are two options for Route Selection: (1) Hop by hop routing, and
and (2) Explicit routing. (2) Explicit routing.
An explicitly routed LSP is an LSP where, at a given LSR, the LSP An explicitly routed LSP is an LSP where, at a given LSR, the LSP next
next hop is not chosen by each local node, but rather is chosen by a hop is not chosen by each local node, but rather is chosen by a single
single node (usually the ingress or egress node of the LSP). The node (usually the ingress or egress node of the LSP). The sequence of
sequence of LSRs followed by an explicit routing LSP may be chosen by LSRs followed by an explicit routing LSP may be chosen by configuration,
configuration, or by an algorithm performed by a single node (for or by an algorithm performed by a single node (for example, the egress
example, the egress node may make use of the topological information node may make use of the topological information learned from a link
learned from a link state database in order to compute the entire state database in order to compute the entire path for the tree ending
path for the tree ending at that egress node). at that egress node).
With MPLS the explicit route needs to be specified at the time that With MPLS the explicit route needs to be specified at the time that
Labels are assigned, but the explicit route does not have to be Labels are assigned, but the explicit route does not have to be
specified with each L3 packet. This implies that explicit routing specified with each L3 packet. This implies that explicit routing with
with MPLS is relatively efficient (when compared with the efficiency MPLS is relatively efficient (when compared with the efficiency of
of explicit routing for pure datagrams). explicit routing for pure datagrams).
Explicit routing may be useful for a number of purposes such as Explicit routing may be useful for a number of purposes such as allowing
allowing policy routing and/or facilitating traffic engineering. policy routing and/or facilitating traffic engineering.
4.10.1 Establishment of Point to Point Explicitly Routed LSPs 4.10.1 Establishment of Point to Point Explicitly Routed LSPs
In order to establish a point to point explicitly routed LSP, the LDP In order to establish a point to point explicitly routed LSP, the LDP
packets used to set up the LSP must contain the explicit route. This packets used to set up the LSP must contain the explicit route. This
implies that the LSP is set up in order either from the ingress to implies that the LSP is set up in order either from the ingress to the
the egress, or from the egress to the ingress. egress, or from the egress to the ingress.
One node needs to pick the explicit route: This may be done in at One node needs to pick the explicit route: This may be done in at least
least two possible ways: (i) by configuration (eg, the explicit route two possible ways: (i) by configuration (eg, the explicit route may be
may be chosen by an operator, or by a centralized server of some chosen by an operator, or by a centralized server of some kind); (ii) By
kind); (ii) By use of a routing protocol which allows the ingress use of a routing protocol which allows the ingress and/or egress node to
and/or egress node to know the entire route to be followed. This know the entire route to be followed. This would imply the use of a link
would imply the use of a link state routing protocol (in which all state routing protocol (in which all nodes know the full topology) or of
nodes know the full topology) or of a path vector routing protocol a path vector routing protocol (in which the ingress node is told the
(in which the ingress node is told the path as part of the normal path as part of the normal operation of the routing protocol).
operation of the routing protocol).
Note: The normal operation of path vector routing protocols (such as Note: The normal operation of path vector routing protocols (such as
BGP) does not provide the full set of routers along the path. This BGP) does not provide the full set of routers along the path. This
implies that either a partial source route only would be provided implies that either a partial source route only would be provided
(implying that LSP setup would use a combination of hop by hop and (implying that LSP setup would use a combination of hop by hop and
explicit routing), or it would be necessary to augment the protocol explicit routing), or it would be necessary to augment the protocol in
in order to provide the complete explicit route. Detailed operation order to provide the complete explicit route. Detailed operation in this
in this case is FFS. case is FFS.
In the point to point case, it is relatively straightforward to In the point to point case, it is relatively straightforward to specify
specify the route to use: This is indicated by providing the the route to use: This is indicated by providing the addresses of each
addresses of each LSR on the LSP. LSR on the LSP.
4.10.2 Explicit and Hop by Hop routing: Avoiding Loops 4.10.2 Explicit and Hop by Hop routing: Avoiding Loops
In general, an LSP will be explicit routed specifically because there In general, an LSP will be explicit routed specifically because there is
is a good reason to use an alternative to the hop by hop routed path. a good reason to use an alternative to the hop by hop routed path. This
This implies that the explicit route is likely to follow a path which implies that the explicit route is likely to follow a path which is
is inconsistent with the path followed by hop by hop routing. If some inconsistent with the path followed by hop by hop routing. If some of
of the nodes along the path follow an explicit route but some of the the nodes along the path follow an explicit route but some of the nodes
nodes make use of hop by hop routing (and ignore the explicit route), make use of hop by hop routing (and ignore the explicit route), then
then inconsistent routing may result and in some cases loops (or inconsistent routing may result and in some cases loops (or severely
severely inefficient paths) may form. This implies that for any one inefficient paths) may form. This implies that for any one LSP, there
LSP, there are two possible options: (i) The entire LSP may be hop by are two possible options: (i) The entire LSP may be hop by hop routed;
hop routed; or (ii) The entire LSP may be explicit routed. or (ii) The entire LSP may be explicit routed.
For this reason, it is important that if an explicit route is For this reason, it is important that if an explicit route is specified
specified for setting up an LSP, then that route must be followed in for setting up an LSP, then that route must be followed in setting up
setting up the LSP. the LSP.
There is a related issue when a link or node in the middle of an There is a related issue when a link or node in the middle of an
explicitly routed LSP breaks: In this case, the last operating node explicitly routed LSP breaks: In this case, the last operating node on
on the upstream part of the LSP will continue receiving packets, but the upstream part of the LSP will continue receiving packets, but will
will not be able to forward them along the explicitly routed LSP not be able to forward them along the explicitly routed LSP (since its
(since its next hop is no longer functioning). In this case, it is next hop is no longer functioning). In this case, it is not in general
not in general safe for this node to forward the packets using L3 safe for this node to forward the packets using L3 forwarding with hop
forwarding with hop by hop routing. Instead, the packets must be by hop routing. Instead, the packets must be discarded, and the upstream
discarded, and the upstream partition of the explicitly routed LSP partition of the explicitly routed LSP must be torn down.
must be torn down.
Where part of an Explicitly Routed LSP breaks, the node which Where part of an Explicitly Routed LSP breaks, the node which originated
originated the LSP needs to be told about this. For robustness the LSP needs to be told about this. For robustness reasons the MPLS
reasons the MPLS protocol design should not assume that the routing protocol design should not assume that the routing protocol will tell
protocol will tell the node which originated the LSP. For example, it the node which originated the LSP. For example, it is possible that a
is possible that a link may go down and come back up quickly enough link may go down and come back up quickly enough that the routing
that the routing protocol never declares the link down. Rather, an protocol never declares the link down. Rather, an explicit MPLS
explicit MPLS mechanism is needed. mechanism is needed.
4.10.3 Merge and Explicit Routing 4.10.3 Merge and Explicit Routing
Explicit Routing is slightly more complex with a multipoint to point Explicit Routing is slightly more complex with a multipoint to point LSP
LSP (i.e., in the case that stream merge is used). (i.e., in the case that stream merge is used).
In this case, it is not possible to specify the route for the LSP as In this case, it is not possible to specify the route for the LSP as a
a simple list of LSRs (since the LSP does not consist of a simple simple list of LSRs (since the LSP does not consist of a simple sequence
sequence of LSRs). Rather the explicit route must specify a tree. of LSRs). Rather the explicit route must specify a tree. There are
There are several ways that this may be accomplished. Details are several ways that this may be accomplished. Details are FFS.
FFS.
4.10.4 Using Explicit Routing for Traffic Engineering 4.10.4 Using Explicit Routing for Traffic Engineering
In the Internet today it is relatively common for ISPs to make use of In the Internet today it is relatively common for ISPs to make use of a
a Frame Relay or ATM core, which interconnects a number of IP Frame Relay or ATM core, which interconnects a number of IP routers. The
routers. The primary reason for use of a switching (L2) core is to primary reason for use of a switching (L2) core is to make use of low
make use of low cost equipment which provides very high speed cost equipment which provides very high speed forwarding. However, there
forwarding. However, there is another very important reason for the is another very important reason for the use of a L2 core: In order to
use of a L2 core: In order to allow for Traffic Engineering. allow for Traffic Engineering.
Traffic Engineering (also known as bandwidth management) refers to Traffic Engineering (also known as bandwidth management) refers to the
the process of managing the routes followed by user data traffic in a process of managing the routes followed by user data traffic in a
network in order to provide relatively equal and efficient loading of network in order to provide relatively equal and efficient loading of
the resources in the network (i.e., to ensure that the bandwidth on the resources in the network (i.e., to ensure that the bandwidth on
links and nodes are within the capabilities of the links and nodes). links and nodes are within the capabilities of the links and nodes).
Some rudimentary level of traffic engineering can be accomplished Some rudimentary level of traffic engineering can be accomplished with
with pure datagram routing and forwarding by adjusting the metrics pure datagram routing and forwarding by adjusting the metrics assigned
assigned to links. For example, suppose that there is a given link in to links. For example, suppose that there is a given link in a network
a network which tends to be overloaded on a long term basis. One which tends to be overloaded on a long term basis. One option would be
option would be to manually configure an increased metric value for to manually configure an increased metric value for this link, in the
this link, in the hopes of moving some traffic onto alternate routes. hopes of moving some traffic onto alternate routes. This provides a
This provides a rather crude method of traffic engineering and rather crude method of traffic engineering and provides only limited
provides only limited results. results.
Another method of traffic engineering is to manually configure Another method of traffic engineering is to manually configure multiple
multiple PVCs across a L2 core, and to adjust the route followed by PVCs across a L2 core, and to adjust the route followed by each PVC in
each PVC in an attempt to equalize the load on different parts of the an attempt to equalize the load on different parts of the network. Where
network. Where necessary, multiple PVCs may be configured between the necessary, multiple PVCs may be configured between the same two nodes,
same two nodes, in order to allow traffic to be split between in order to allow traffic to be split between different paths. In some
different paths. In some topologies it is much easier to achieve topologies it is much easier to achieve efficient non-overlapping or
efficient non-overlapping or minimally-overlapping paths via this minimally-overlapping paths via this method (with manually configured
method (with manually configured paths) than it would be with pure paths) than it would be with pure datagram forwarding. A similar ability
datagram forwarding. A similar ability can be achieved with MPLS via can be achieved with MPLS via the use of manual configuration of the
the use of manual configuration of the paths taken by LSPs. paths taken by LSPs.
A related issue is the decision on where merge is to occur. Note that A related issue is the decision on where merge is to occur. Note that
once two streams merge into one stream (forwarded by a single label) once two streams merge into one stream (forwarded by a single label)
then they cannot diverge again at that level of the MPLS hierarchy then they cannot diverge again at that level of the MPLS hierarchy
(i.e., they cannot be bifurcated without looking at a higher level (i.e., they cannot be bifurcated without looking at a higher level label
label or the IP header). Thus there may be times when it is desirable or the IP header). Thus there may be times when it is desirable to
to explicitly NOT merge two streams even though they are to the same explicitly NOT merge two streams even though they are to the same egress
egress node and FEC. Non-merge may be appropriate either because the node and FEC. Non-merge may be appropriate either because the streams
streams will want to diverge later in the path (for example, to avoid will want to diverge later in the path (for example, to avoid
overloading a particular downstream link), or because the streams may overloading a particular downstream link), or because the streams may
want to use different physical links in the case where multiple want to use different physical links in the case where multiple slower
slower physical links are being aggregated into a single logical link physical links are being aggregated into a single logical link for the
for the purpose of IP routing. purpose of IP routing.
As a network grows to a very large size (on the order of hundreds of As a network grows to a very large size (on the order of hundreds of
LSRs), it becomes increasingly difficult to handle the assignment of LSRs), it becomes increasingly difficult to handle the assignment of all
all routes via manual configuration. However, explicit routing allows routes via manual configuration. However, explicit routing allows
several alternatives: several alternatives:
1. Partial Configuration: One option is to use automatic/dynamic 1. Partial Configuration: One option is to use automatic/dynamic routing
routing for most of the paths through the network, but then manually for most of the paths through the network, but then manually configure
configure some routes. For example, suppose that full dynamic routing some routes. For example, suppose that full dynamic routing would result
would result in a particular link being overloaded. One of the LSPs in a particular link being overloaded. One of the LSPs which uses that
which uses that link could be selected and manually routed to use a link could be selected and manually routed to use a different path.
different path.
2. Central Computation: One option would be to provide long term 2. Central Computation: One option would be to provide long term network
network usage information to a single central management facility. usage information to a single central management facility. That facility
That facility could then run a global optimization to compute a set could then run a global optimization to compute a set of paths to use.
of paths to use. Network management commands can be used to configure Network management commands can be used to configure LSRs with the
LSRs with the correct routes to use. correct routes to use.
3. Egress Computation: An egress node can run a computation which 3. Egress Computation: An egress node can run a computation which
optimizes the path followed for traffic to itself. This cannot of optimizes the path followed for traffic to itself. This cannot of course
course optimize the entire traffic load through the network, but can optimize the entire traffic load through the network, but can include
include optimization of traffic from multiple ingress's to one optimization of traffic from multiple ingress's to one egress. The
egress. The reason for optimizing traffic to a single egress, rather reason for optimizing traffic to a single egress, rather than from a
than from a single ingress, relates to the issue of when to merge: An single ingress, relates to the issue of when to merge: An ingress can
ingress can never merge the traffic from itself to different never merge the traffic from itself to different egresses, but an egress
egresses, but an egress can if desired chose to merge the traffic can if desired chose to merge the traffic from multiple ingress's to
from multiple ingress's to itself. itself.
4.10.5 Using Explicit Routing for Policy Routing 4.10.5 Using Explicit Routing for Policy Routing
This section is FFS. This section is FFS.
4.11 Traceroute 4.11 Traceroute
This section is FFS. This section is FFS.
4.12 LSP Control: Egress versus Local 4.12 LSP Control: Egress versus Local
There is a choice to be made regarding whether the initial setup of There is a choice to be made regarding whether the initial setup of LSPs
LSPs will be initiated by the egress node, or locally by each will be initiated by the egress node, or locally by each individual
individual node. node.
When LSP control is done locally, then each node may at any time pass When LSP control is done locally, then each node may at any time pass
label bindings to its neighbors for each FEC recognized by that node. label bindings to its neighbors for each FEC recognized by that node. In
In the normal case that the neighboring nodes recognize the same the normal case that the neighboring nodes recognize the same FECs, then
FECs, then nodes may map incoming labels to outgoing labels as part nodes may map incoming labels to outgoing labels as part of the normal
of the normal label swapping forwarding method. label swapping forwarding method.
When LSP control is done by the egress, then initially (on startup) When LSP control is done by the egress, then initially (on startup) only
only the egress node passes label bindings to its neighbors the egress node passes label bindings to its neighbors corresponding to
corresponding to any FECs which leave the MPLS network at that egress any FECs which leave the MPLS network at that egress node. When
node. When initializing, other nodes wait until they get a label from initializing, other nodes wait until they get a label from downstream
downstream for a particular FEC before passing a corresponding label for a particular FEC before passing a corresponding label for the same
for the same FEC to upstream nodes. FEC to upstream nodes.
With local control, since each LSR is (at least initially) With local control, since each LSR is (at least initially) independently
independently assigning labels to FECs, it is possible that different assigning labels to FECs, it is possible that different LSRs may make
LSRs may make inconsistent decisions. For example, an upstream LSR inconsistent decisions. For example, an upstream LSR may make a coarse
may make a coarse decision (map multiple IP address prefixes to a decision (map multiple IP address prefixes to a single label) while its
single label) while its downstream neighbor makes a finer grain downstream neighbor makes a finer grain decision (map each individual IP
decision (map each individual IP address prefix to a separate label). address prefix to a separate label). With downstream label assignment
With downstream label assignment this can be corrected by having LSRs this can be corrected by having LSRs withdraw labels that it has
withdraw labels that it has assigned which are inconsistent with assigned which are inconsistent with downstream labels, and replace them
downstream labels, and replace them with new consistent label with new consistent label assignments.
assignments.
This may appear to be an advantage of egress LSP control (since with This may appear to be an advantage of egress LSP control (since with
egress control the initial label assignments "bubble up" from the egress control the initial label assignments "bubble up" from the egress
egress to upstream nodes, and consistency is therefore easy to to upstream nodes, and consistency is therefore easy to ensure).
ensure). However, even with egress control it is possible that the However, even with egress control it is possible that the choice of
choice of egress node may change, or the egress may (based on a egress node may change, or the egress may (based on a change in
change in configuration) change its mind in terms of the granularity configuration) change its mind in terms of the granularity which is to
which is to be used. This implies the same mechanism will be be used. This implies the same mechanism will be necessary to allow
necessary to allow changes in granularity to bubble up to upstream changes in granularity to bubble up to upstream nodes. The choice of
nodes. The choice of egress or local control may therefore effect the egress or local control may therefore effect the frequency with which
frequency with which this mechanism is used, but will not effect the this mechanism is used, but will not effect the need for a mechanism to
need for a mechanism to achieve consistency of label granularity. achieve consistency of label granularity.
Egress control and local control can interwork in a very Egress control and local control can interwork in a very straightforward
straightforward manner: With either approach, (assuming downstream manner: With either approach, (assuming downstream label assignment) the
label assignment) the egress node will initially assign labels for egress node will initially assign labels for particular FECs and will
particular FECs and will pass these labels to its neighbors. With pass these labels to its neighbors. With either approach these label
either approach these label assignments will bubble upstream, with assignments will bubble upstream, with the upstream nodes choosing
the upstream nodes choosing labels that are consistent with the labels that are consistent with the labels that they receive from
labels that they receive from downstream. downstream.
The difference between the two techniques therefore becomes a The difference between the two techniques therefore becomes a tradeoff
tradeoff between avoiding a short period of initial thrashing on between avoiding a short period of initial thrashing on startup (in the
startup (in the sense of avoiding the need to withdraw inconsistent sense of avoiding the need to withdraw inconsistent labels which may
labels which may have been assigned using local control) versus the have been assigned using local control) versus the imposition of a short
imposition of a short delay on initial startup (while waiting for the delay on initial startup (while waiting for the initial label
initial label assignments to bubble up from downstream). The protocol assignments to bubble up from downstream). The protocol mechanisms which
mechanisms which need to be defined are the same in either case, and need to be defined are the same in either case, and the steady state
the steady state operation is the same in either case. operation is the same in either case.
4.13 Security 4.13 Security
Security in a network using MPLS should be relatively similar to Security in a network using MPLS should be relatively similar to
security in a normal IP network. security in a normal IP network.
Routing in an MPLS network uses precisely the same IP routing Routing in an MPLS network uses precisely the same IP routing protocols
protocols as are currently used with IP. This implies that route as are currently used with IP. This implies that route filtering is
filtering is unchanged from current operation. Similarly, the unchanged from current operation. Similarly, the security of the routing
security of the routing protocols is not effected by the use of MPLS. protocols is not effected by the use of MPLS.
Packet filtering also may be done as in normal IP. This will require Packet filtering also may be done as in normal IP. This will require
either (i) that label swapping be terminated prior to any firewalls either (i) that label swapping be terminated prior to any firewalls
performing packet filtering (in which case a separate instance of performing packet filtering (in which case a separate instance of label
label swapping may optionally be started after the firewall); or (ii) swapping may optionally be started after the firewall); or (ii) that
that firewalls "look past the labels", in order to inspect the entire firewalls "look past the labels", in order to inspect the entire IP
IP packet contents. In this latter case note that the label may imply packet contents. In this latter case note that the label may imply
semantics greater than that contained in the packet header: In semantics greater than that contained in the packet header: In
particular, a particular label value may imply that the packet is to particular, a particular label value may imply that the packet is to
take a particular path after the firewall. In environments in which take a particular path after the firewall. In environments in which this
this is considered to be a security issue it may be desirable to is considered to be a security issue it may be desirable to terminate
terminate the label prior to the firewall. the label prior to the firewall.
Note that in principle labels could be used to speed up the operation Note that in principle labels could be used to speed up the operation of
of firewalls: In particular, the label could be used as an index into firewalls: In particular, the label could be used as an index into a
a table which indicates the characteristics that the packet needs to table which indicates the characteristics that the packet needs to have
have in order to pass through the firewall. Depending upon in order to pass through the firewall. Depending upon implementation
implementation considerations matching the contents of the packet to considerations matching the contents of the packet to the contents of
the contents of the table may be quicker than parsing the packet in the table may be quicker than parsing the packet in the absence of the
the absence of the label. label.
References References
[1] "A Proposed Architecture for MPLS", E. Rosen, A. Viswanathan, R. [1] "A Proposed Architecture for MPLS", E. Rosen, A. Viswanathan, R.
Callon, work in progress, draft-rosen-architecture-00.txt, July Callon, work in progress, draft-ietf-mpls-arch-00.txt, August
1997. 1997.
[2] "ARIS: Aggregate Route-Based IP Switching", A. Viswanathan, N. [2] "ARIS: Aggregate Route-Based IP Switching", A. Viswanathan, N.
Feldman, R. Boivie, R. Woundy, work in progress, Internet Draft Feldman, R. Boivie, R. Woundy, work in progress, Internet Draft
<draft- viswanathan-aris-overview-00.txt>, March 1997. <draft- viswanathan-aris-overview-00.txt>, March 1997.
[3] "ARIS Specification", N. Feldman, A. Viswanathan, work in [3] "ARIS Specification", N. Feldman, A. Viswanathan, work in
progress, Internet Draft <draft-feldman-aris-spec-00.txt>, March progress, Internet Draft <draft-feldman-aris-spec-00.txt>, March
1997. 1997.
[4] "ARIS Support for LAN Media Switching", S. Blake, A. Ghanwani, W. [4] "ARIS Support for LAN Media Switching", S. Blake, A. Ghanwani, W.
Pace, V. Srinivasan, work in progress, Internet Draft <draft- Pace, V. Srinivasan, work in progress, Internet Draft <draft-
blake-aris-lan- 00.txt>, March 1997. blake-aris-lan- 00.txt>, March 1997.
[5] "Tag Switching Architecture - Overview", Rekhter, Davie, Katz, [5] "Tag Switching Architecture - Overview", Rekhter, Davie, Katz,
Rosen, Swallow, Farinacci, work in progress, Internet Draft Rosen, Swallow, Farinacci, work in progress, Internet Draft
<draft-rekhter- tagswitch-arch-00.txt> <draft-rekhter- tagswitch-arch-01.txt>, July 1997.
[6] Tag distribution Protocol", Doolan, Davie, Katz, Rekhter, Rosen, [6] Tag distribution Protocol", Doolan, Davie, Katz, Rekhter, Rosen,
work in progress, internet draft <draft-doolan-tdp-spec-01.txt> work in progress, internet draft <draft-doolan-tdp-spec-01.txt>
[7] "Use of Tag Switching with ATM", Davie, Doolan, Lawrence, [7] "Use of Tag Switching with ATM", Davie, Doolan, Lawrence,
McGloghrie, Rekhter, Rosen, Swallow, work in progress, Internet McGloghrie, Rekhter, Rosen, Swallow, work in progress, Internet
Draft <draft-davie- tag-switching-atm-01.txt> Draft <draft-davie- tag-switching-atm-01.txt>
[8] "Label Switching: Label Stack Encodings", Rosen, Rekhter, Tappan, [8] "MPLS Label Stack Encoding", Rosen, Rekhter, Tappan, Farinacci,
Farinacci, Fedorkow, Li, work in progress, internet draft Fedorkow, Li, Conta, work in progress, draft-ietf-mpls-label-
<draft-rosen- tag-stack-02.txt> encaps-00.txt, November 1997.
[9] "Partitioning Tag Space among Multicast Routers on a Common [9] "Partitioning Tag Space among Multicast Routers on a Common
Subnet", Farinacci, work in progress, internet draft <draft- Subnet", Farinacci, work in progress, internet draft <draft-
farinacci-multicast- tag-part-00.txt> farinacci-multicast- tag-part-00.txt>
[10] "Multicast Tag Binding and Distribution using PIM", Farinacci, [10] "Multicast Tag Binding and Distribution using PIM", Farinacci,
Rekhter, work in progress, internet draft <draft-farinacci- Rekhter, work in progress, internet draft <draft-farinacci-
multicast-tagsw- 00.txt> multicast-tagsw- 00.txt>
[11] "Toshiba's Router Architecture Extensions fir ATM: Overview", [11] "Toshiba's Router Architecture Extensions for ATM: Overview",
Katsube, Nagami, Esaki, RFC2098.TXT. Katsube, Nagami, Esaki, RFC2098.TXT.
[12] "Soft State Switching: A Proposal to Extend RSVP for Switching [12] "Soft State Switching: A Proposal to Extend RSVP for Switching
RSVP Flows", A. Viswanathan, V. Srinivasan, work in progress, RSVP Flows", A. Viswanathan, V. Srinivasan, work in progress,
Internet Draft <draft-viswanathan-aris-rsvp-00.txt>, March 1997. Internet Draft <draft-viswanathan-aris-rsvp-00.txt>, March 1997.
[13] "Integrated Services in the Internet Architecture: an Overview", [13] "Integrated Services in the Internet Architecture: an Overview",
R. Braden et al, RFC 1633, June 1994. R. Braden et al, RFC 1633, June 1994.
[14] "Resource ReSerVation Protocol (RSVP), Version 1 Functional [14] "Resource ReSerVation Protocol (RSVP), Version 1 Functional
skipping to change at page 51, line 16 skipping to change at page 64, line 5
[16] "A Border Gateway Protocol 4 (BGP-4)", Y. Rekhter and T. Li, [16] "A Border Gateway Protocol 4 (BGP-4)", Y. Rekhter and T. Li,
RFC 1771, March 1995. RFC 1771, March 1995.
[17] "Ipsilon Flow Management Protocol Specification for IPv4 Version [17] "Ipsilon Flow Management Protocol Specification for IPv4 Version
1.0", P. Newman et al., RFC 1953, May 1996. 1.0", P. Newman et al., RFC 1953, May 1996.
[18] "ATM Forum Private Network-Network Interface Specification, [18] "ATM Forum Private Network-Network Interface Specification,
Version 1.0", ATM Forum af-pnni-0055.000, March 1996. Version 1.0", ATM Forum af-pnni-0055.000, March 1996.
[19] "NBMA Next Hop Resolution Protocol (NHRP)", J. Luciani et al., [19] "NBMA Next Hop Resolution Protocol (NHRP)", Luciani, Katz,
work in progress, draft-ietf-rolc-nhrp-11.txt, March 1997. Piscitello, Cole, work in progress, draft-ietf-rolc-nhrp-12.txt,
March 1998.
Author's Addresses Author's Addresses
Ross Callon Ross Callon
Ascend Communications, Inc. Ascend Communications, Inc.
1 Robbins Road 1 Robbins Road
Westford, MA 01886 Westford, MA 01886
508-952-7412 508-952-7412
rcallon@casc.com rcallon@casc.com
Paul Doolan Paul Doolan
Cisco Systems, Inc Ennovate Networks
250 Apollo Drive 330 Codman Hill Road
Chelmsford, MA 01824 Boxborough, MA
508-634-1204 978-263-2002 x103
pdoolan@cisco.com pdoolan@ennovatenetworks.com
Nancy Feldman Nancy Feldman
IBM Corp. IBM Corp.
17 Skyline Drive 17 Skyline Drive
Hawthorne NY 10532 Hawthorne NY 10532
914-784-3254 914-784-3254
nkf@vnet.ibm.com nkf@vnet.ibm.com
Andre Fredette Andre Fredette
Bay Networks Inc Bay Networks Inc
 End of changes. 75 change blocks. 
327 lines changed or deleted 950 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/