Internet Draft
Internet Draft A. Fredette
Expires May 1998 Bay Networks, Inc.
C. White
Bay Networks, Inc.
Loa Andersson
Ericsson Telecom
Paul Doolan
Ennovate Networks
November 1997
Stream Aggregation
<draft-fredette-mpls-aggregation-00.txt>
Status of this Memo
This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as ``work in progress.''
To learn the current status of any Internet-Draft, please check the
``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow
Directories on ds.internic.net (US East Coast), nic.nordu.net
(Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific
Rim).
Abstract
This document describes issues with aggregating streams of data in an
MPLS system and suggests alternatives for increasing the level of
aggregation possible.
1. Introduction
Fredette, White, Andersson, Doolan [Page 1]
INTERNET-DRAFT Stream Aggregation Expires May 1998
One of the important areas for the application of MPLS is in ATM
switching hardware. It has been recognized that non-VC-merging ATM
switches (the most common in existence today) require a significantly
larger number of labels than merge-capable switches. This number can
be even larger than many have realized if stream aggregation is not
applied intelligently. In Section 3, we examine the different levels
of stream aggregation that are possible. Then, in Section 4, we
discuss possible solutions for achieving the highest possible level
of aggregation.
2. Terminology
Terms used in this document are aligned as much as possible with
definitions provided in the MPLS Framework document [MPLS-F].
Flow
A single instance of an application to application flow of data (as
in the RSVP and IFMP use of the term "flow")
Stream
An aggregate of one or more flows, treated as one aggregate for the
purpose of forwarding in L2 and/or L3 nodes (e.g., may be described
using a single label). In many cases a stream may be the aggregate
of a very large number of flows. Synonymous with "aggregate
stream".
merged stream
An aggregate of one or more streams such that the decision to
aggregate is local to the merging LSR.
aggregated stream
An aggregate of one or more streams such that the decision to
aggregate is made by some downstream LSR.
MPLS domain
a contiguous set of nodes which operate MPLS routing and forwarding
and which are also in one Routing or Administrative Domain
merge capable
An LSR capable of merging frames received with different labels
onto the same outgoing interface with the same label. The ATM
Fredette, White, Andersson, Doolan [Page 2]
INTERNET-DRAFT Stream Aggregation Expires May 1998
specific case, VC- merge capable, is the capability of an ATM
switch to merge cell streams without interleaving cells from
different AAL5 frames.
Port
Logical port that represents an ingress to an LSR. A single
physical interface may support multiple logical ports.
Note, in this document, the term stream may refer either to a single
flow or an aggregate of multiple flows or streams. A flow, however,
can never refer to a stream that is an aggregate.
The difference between a merged stream and an aggregated stream is
subtle. In particular, the term "aggregated stream" is somewhat
overloading the word aggregate. For the purpose of this document,
the terms "aggregate" and "aggregation" are used only in reference to
"aggregated streams", and are not used in reference to merged
streams.
3. Overview
It is useful for an MPLS network to aggregate streams that share the
same ingress-egress pair through a routing domain. For example,
consider the network in Figure 1
S1--A-------+
| +-D1
| |
C-------D-+
| |
| +-D2
S2--B-------+
Figure 1: Sample MPLS Network
MPLS is used on internal links. Given sources S1 and S2 and
destinations D1 and D2, consider four best effort traffic streams:
- S1-A-C-D-D1
- S1-A-C-D-D2
- S2-B-C-D-D1
- S2-B-C-D-D2
Fredette, White, Andersson, Doolan [Page 3]
INTERNET-DRAFT Stream Aggregation Expires May 1998
All four streams use LSR D as the egress LSR of the MPLS domain.
Given that all four streams share the same stream descriptor (e.g.,
they are all best effort), from the perspective of MPLS, it is
irrelevant that D1 and D2 are separate destinations. In this figure,
relative to these four streams, LSRs A and B are Ingress LSRs and LSR
D is an Egress LSR. We assume that LSRs A and B are merge capable.
Stream aggregation allows streams that share a common Ingress LSR (or
set of Ingress LSRs), Egress LSR and FEC to be aggregated into an
aggregate stream, thus reducing label consumption within the MPLS
network.
Sections 3.1 - 3.4 describe each of four different possibilities for
assigning labels. Note that downstream label allocation on demand is
used for the examples, although this is not necessarily a
requirement.
3.1 No Merge, No Aggregation
In the worst case, none of the internal switches are capable of
merging and no aggregation is performed. At each LSR, a different
label must be allocated for each label request received from an
upstream neighbor. There is no means of determining which label
requests can be aggregated.
For example, in Figure 1, LSR A makes independent label requests for
D1 and D2 to LSR C, its next hop. LSR B makes two similar requests.
Since LSR C is unable to perform merge, it requests two different
labels for D1 and two different labels for D2 from LSR D. LSR D
receives four label requests. From LSR Ds perspective, D1 and D2 are
in the same forwarding equivalence class (FEC), but because LSR D is
unaware of the history of the requests, it must respond
conservatively and assign a different label for each request.
In this example, the "history" of a request refers to information
that indicates the source of the request as well as the path taken.
Without this information, it is not possible for LSR D to distinguish
requests originated by LSR A from those originated by LSR B.
In networks that do not support merge and do not perform aggregation,
the number of LSPs setup can be expressed as:
LSPs = O(N^2 * D)
N = Number of ingress LSRs = Number of egress LSRs (every
ingress is also an egress)
Fredette, White, Andersson, Doolan [Page 4]
INTERNET-DRAFT Stream Aggregation Expires May 1998
D = Number of destination addresses per egress LSR
This follows from the fact that for every route that appears in an
ingress LSRs routing table, the LSR must request a separate label,
generating a separate LSP. Each ingress LSR will generate D LSPs to
each of N-1 egress LSRs. There are N ingress LSRs yielding O(N^2 *
D) LSPs for the entire network. A label space of this size can be
particularly problematical since D can easily be greater than O(N^2)
for a given routing domain.
3.2 No Merge With Aggregation
If it is possible to aggregate all the streams that share an LSP,
labels can be conserved. This is accomplished by including
information with each label request that uniquely identifies the path
that the request followed. This allows the egress LSR to assign a
single label for all requests that share the same path.
In the network shown in Figure 1, LSR A still makes two independent
label requests for D1 and D2, but attaches information that "A" is
the source of each request. LSR C in turn makes two requests for D1
and D2, but retains "A" as the source of the request. Similarly, LSR
B generates two requests which are propagated by LSR C indicating "B"
as the source.
When LSR D receives the four independent requests, it can assign a
single label for the two requests from source "A". Likewise it can
assign a single label for the two requests from source "B".
In networks that do not support merge but do perform aggregation, the
number of LSPs setup can be expressed as:
LSPs = O(N^2)
N = Number of ingress LSRs = Number of egress LSRs
D = Number of destination addresses per egress LSR
This is an improvement of O(D) over the previous example without
aggregation.
3.3 Merge, No Aggregation
When LSRs are capable of merging VCs, the number of separate VCs used
in the network is significantly reduced. Let's now assume that LSR C
in Figure 1 is capable of merging. Here, no aggregation is
Fredette, White, Andersson, Doolan [Page 5]
INTERNET-DRAFT Stream Aggregation Expires May 1998
performed.
LSR A makes independent label request for D1 and D2 to LSR C. LSR B
makes two similar requests. Since LSR C is now able to merge, it
requests from LSR D only a single label for D1 and a single label for
D2. The egress LSR D then receives only two label requests. If LSR D
is unaware of the capabilities of LSR C, LSR D must respond
conservatively and assign a different label for each request.
In networks that support Merge but do not perform aggregation, the
number of LSPs setup can be expressed as:
LSPs = O(N*D)
N = Number of ingress LSRs = Number of egress LSRs
D = Number of destination addresses per egress LSR
It should be noted, however, that in a system of fully merge capable
LSRs, a downstream LSR may aggregate as it desires as is described in
the next section.
3.4 Merge With Aggregation
The optimal case is when the network is capable of merging and
aggregation is performed. In this case, a single multipoint to point
LSP is used for all traffic to the egress LSR, regardless of the
final destination beyond the LSR.
Let's again assume that LSR C in Figure 1 is capable of merging. LSR
A makes two independent label requests for D1 and D2, but attaches
information that "A" is the source of each request. LSR B makes two
similar requests. Since LSR C is now able to perform merge, it
requests from LSR D only a single label for D1 and another for D2,
however, since LSR C is capable of merge, it changes the attached
information to indicate that "C" is the source of the request (acting
like an ingress LSR).
When LSR D receives the two requests, it can assign a single label
for both requests since they share the same "source" LSR.
In networks that support both merge and aggregation, the number of
LSPs setup can be expressed as:
LSPs = O(N)
N = Number of ingress LSRs = Number of egress LSRs
Fredette, White, Andersson, Doolan [Page 6]
INTERNET-DRAFT Stream Aggregation Expires May 1998
D = Number of destination addresses per egress LSR
This is an improvement of O(D) over the previous example without
aggregation. In general, aggregation will yield an improvement on
the order of the number of destination routes per LSR.
Using egress-based aggregation significantly reduces label
consumption within the MPLS network. This leads to a best case of
one label per egress per hop and a worst case of one label per
ingress/egress pair per hop in the MPLS domain. The best case can be
achieved by a network fully supporting merge. The worst case is seen
when using all non-merge capable LSRs, as this leads to a full-mesh
of LSPs between all LSRs.
4. Stream Aggregation
An aggregated stream can be described in terms of the Merge LSR,
Intermediate LSRs, and the Egress LSR. In Figure 2, the Merge LSR
(LSR A) is the first LSR of the aggregated stream and is responsible
for merging frames from multiple streams onto the same LSP with the
same label. Intermediate LSRs (LSR B) simply forward the data along
the LSP and require no special forwarding capabilities. The Egress
LSR (LSR C) is the last LSR in the aggregated path and is responsible
for de- aggregating the streams from the merged LSP.
+-D1
|
S1--A-------B-------C-+
|
+-D2
Figure 2 An Aggregated Stream: Merge LSR, Intermediate LSRs and Egress LSR
A common scenario could be where the Merge LSR is an L3 router and is
the ingress LSR to the MPLS domain. Similarly, the Egress LSR could
be an L3 router and be the egress LSR from the MPLS domain.
The following sub-sections describe several possibilities for
achieving stream aggregation.
4.1 Merge LSR "Hides" Aggregation
Merge LSR A analyzes the routed path for both D1 and D2 and decides
that the LSP to Egress LSR C is the same for both destinations. LSR
A requests a label only for D1. The LSP for D1 is set up normally.
Fredette, White, Andersson, Doolan [Page 7]
INTERNET-DRAFT Stream Aggregation Expires May 1998
LSR A forwards data destined for D2 using the label assigned for D1.
Note that since the routing protocol boundary need not coincide with
the MPLS boundary, additional information is required in the routing
protocol to indicate which hops are MPLS LSRs such that when MPLS
analyzes the routed path, it can determine the extent of the MPLS
path. With OSPF, this could be accomplished by adding an opaque LSA
that is advertised by all LSRs.
This method hides the fact that D2 data is being aggregated onto the
same LSP used for D1. LSR A is the only node that is aware of any
aggregation taking place. This approach defeats the capability of
Egress LSR D to assign different labels for D1 and D2. When
downstream allocation is used, LSR D assigns a label for D1 and may
reasonably assume that only D1 traffic will arrive with this label.
Traffic for D2 will be unexpected and may inadvertently be dropped as
an error.
4.2 Merge LSR Aggregates to Egress LSR
In an approach similar to the one described in Section 4.1, each LSR
in a given OSPF area can request an LSP to each other LSR in the
area. Then, it can use its link-state database to determine which
routes should be forwarded to which egress LSR. This approach is
preferable the one described in Section 4.1 because the LSP ends at
the router and is not overloaded.
For example, in Figure 2, LSR A requests labels for LSRs B and C.
Then, it uses its link-state database to determine that LSR C is the
egress for D1 and D2. After making this determination, LSR A can use
the label for C on packets destined for D1 and D2.
One may note that this approach is similar to the one described in
[ARA] and [HEIN].
4.3 Merge LSR Groups Requests
Again, Merge LSR A analyzes the routed path for both D1 and D2 and
decides that the LSP to Egress LSR C is the same for both
destinations. LSR A groups label requests for D1 and D2.
Intermediate LSR B maintains this grouping until Egress LSR C
receives the grouped request. LSR C assigns a single label for all
requests in the same group.
This approach allows the egress to choose whether to reply with the
same label for the two destinations. The major problem with this
Fredette, White, Andersson, Doolan [Page 8]
INTERNET-DRAFT Stream Aggregation Expires May 1998
approach is the overhead involved in dealing with topology changes.
Each topology change that affects the members of a group requires
that a new request be generated containing the all members of the
group. For example, if D2 were to become available at a different
Egress LSR, the original grouping with D1 would have to be re-
established with only D1. This is in addition to establishing a
group for D2 to the new Egress LSR.
4.4 Merge LSR ID in Requests
The key issue in aggregating multiple requests is the ability to
identify groups of requests that follow the same path, and can thus
be assigned to the same LSP. The previous sections describe methods
to solve this with brute force by having the Merge LSR determine and
maintain the groups. Use of the Merge LSR ID, and the next section
use of a Merge ID rely on the Egress LSR to determine which requests
can be grouped. The burden of maintaining the grouping throughout
topology changes is distributed among all LSRs in the path.
Information could be added to each label request that would uniquely
identify the merge LSR. This would allow the Egress LSR an indication
about which requests can be aggregated. For example, in the network
in Figure 3, LSR A generates a label request for D1 and another for
D2, attaching "A" as the Merge LSR ID. LSR C (not merge capable)
propagates these requests on to LSR D, leaving the Merge LSR ID as
"A" for both requests. LSR D can easily aggregate the two requests
since they share the same Merge LSR ID.
S1--A-------+
| +-D1
| |
C-------D-+
| |
| +-D2
S2--B-------+
Figure 3 Using Merge LSR ID for Flow Aggregation
Since the Merge LSR ID is attached to each label request
independently, topology changes are easily handled. If a new
destination D3 appeared off of D, LSR A would generate a single
request for D3 with "A" as the Merge LSR ID. LSR C propagates the
request to LSR D who can determine that the same label used for the
previous requests from Merge LSR A can be used.
This approach suffers in that it only identifies unique Merge LSRs
and not unique paths from a given Merge LSR. As shown in more detail
in the next section, if packets from a given Merge LSR to a given
Fredette, White, Andersson, Doolan [Page 9]
INTERNET-DRAFT Stream Aggregation Expires May 1998
Egress LSR can take different paths, merging can be inappropriately
applied and cell interleaving can occur. This approach, therefore,
is not adequate.
4.5 Merge Identifier (MID) in Label Binding Requests
A slight modification to the previous algorithm solves the problem of
identifying unique paths from a Merge LSR to an Egress LSR. A Merge
Identifier (MID) is used to identify unique paths that traverse a
given link. Similar to labels, the MID only has local significance
between two LSRs and is mapped to a different MID at each hop on a
path.
MID values are assigned by the upstream neighbor and are included
with each label request. As a label request progresses from Merge
LSR to Egress LSR, the MID is mapped at each intermediate hop. At
any given link, all requests with the same MID are guaranteed to
share the same path from the same Merge LSR. Thus, at the Egress
LSR, all requests sharing the same MID can be safely aggregated onto
the same LSP.
Figure 4 shows a possible MID mapping from two Merge LSRs, A and B,
to a common Egress LSR D. Note that in this figure, LSR C is not
capable of merge, and thus is an Intermediate LSR.
MID=0
S1--A-------+
| +-D1
| MID=3 |
C-------D-+
| MID=2 |
| +-D2
S2--B-------+
MID=0
Figure 4 MID mappings to indicate unique Merge LSRs
Each label request that LSR A originates includes an MID=0 (Null).
When LSR C receives a label request from A that must be propagated to
LSR D, LSR C allocates a unique MID=3 and maps to
. It propagates the request to D with MID=3. LSR B
uses MID=0, LSR C maps to .
Label requests received at D will have either an MID=3 (corresponding
to LSP A-C-D) or MID=2 (corresponding to LSP B-C-D). Regardless of
the number of label requests generated by LSR A, LSR D can use the
same label as long as the traffic descriptor for the requests is the
same.
Fredette, White, Andersson, Doolan [Page 10]
INTERNET-DRAFT Stream Aggregation Expires May 1998
The need for MID mappings is clear when considering multiple paths
from the same Merge LSR to the same Egress LSR. This may result, for
example, from multiple equal cost paths generated by the routing
protocol yielding a different next hop for different prefixes.
Figure 5 illustrates two separate paths from Merge LSR A to Egress
LSR E: A-B-D-E and A-C-D-E. If the Merge LSR ID approach from
Section 4.4 were used, LSR E would incorrectly assume that it could
use the same label for both requests. Then, when the streams are
merged at LSR D, cell interleaving can occur.
It is important to note here that a similar problem can occur when
using VP merge. In a commonly discussed approach, each ingress LSR
has a unique VCI that is uses in the transmission of frames on all
VPIs. If the multipath condition described above occurs, cell
interleaving can occur at LSR D.
MID=0 MID=5
+-------B-------+
| | +-D1
| | MID=3 |
S1--A D-------E-+
| | MID=2 |
| | +-D2
+-------C-------+
MID=0 MID=6
Figure 5 MID mappings to indicate unique paths from same Merge LSR
In order for the egress to properly aggregate streams from LSR A,
Egress LSR E must be able to discern which path a request used.
Using only the Merge LSR ID in the request would result in LSR E
assigning the same label for all requests from LSR A. This results
in LSR D using the same outgoing label for streams from two different
incoming interfaces. As LSR D is not merge capable, it would
incorrectly merge/interleave cells from frames received from LSRs B
and C.
4.5.1 MID Tree
The mapping of MID values from Merge LSR to all possible Egress LSRs
forms a point-to-multipoint tree rooted at the Merge LSR. The leaves
of the tree are the Egress LSRs. All other LSRs are Intermediate
LSRs and are not merge capable.
The path from the Merge LSR to any Egress LSR on the MID tree is the
same as a valid routed data path. For any link on the MID tree, the
MID value used corresponds directly to a unique path from the Merge
Fredette, White, Andersson, Doolan [Page 11]
INTERNET-DRAFT Stream Aggregation Expires May 1998
LSR.
On any given link the number of MID values in use represents the
number of unique paths from all Merge LSRs that cross this link.
4.5.2 Merge Capable LSRs
In the event that an LSR in the middle of the MPLS domain is merge-
capable, the LSR simply acts as an Egress LSR to upstream neighbors
and as a Merge LSR to downstream neighbors. For example, in the
previous example (shown in Figure 5), if LSR D were merge-capable, it
would perform aggregation of requests from upstream neighbors B and
C. It would use a MID=0 for requests to LSR E allowing E to use a
single label. Figure 6 demonstrates the resulting LSPs and MID
mappings.
MID=0 MID=5
+-------B-------+
| | +-D1
| | MID=0 |
S1--A D-------E-+
| | MID=0 |
| | +-D2
+-------C-------+
MID=0 MID=6
Figure 6 Merge LSRs in the middle of an MPLS domain
Note that each Merge LSR only uses single MID per interface (assuming
it is Merge LSR for all LSPs traversing this LSR). Since the
interfaces are independent, the same MID can be used for each
interface. In this case, the NULL MID of 0 can always be used. In a
network of only Merge- capable LSRs, the MID can always be left as
NULL.
Similar to label mappings, mapping of MIDs must include port
information as well. Thus the tuple maps to
.
4.5.3 Operation of Merge LSRs
The Merge LSR is the first LSR in the aggregate stream. It makes no
decisions regarding which outgoing streams can be aggregated. There
is no snooping of the routing table and no changes to the routing
protocol.
Fredette, White, Andersson, Doolan [Page 12]
INTERNET-DRAFT Stream Aggregation Expires May 1998
Operating conservatively, the Merge LSR makes independent label
requests just as it would without considering stream aggregation.
However, for each request generated, it attaches a MID=0, indicating
to the downstream LSR that it is acceptable to aggregate the stream
associated with this request with any other previous binding. (Note
that for an LSR operating as a Merge LSR for some LSPs and as an
Intermediate LSR for others, the MID would not always be NULL.)
When label bindings are received from downstream, the Merge LSR
simply incorporates the bindings into the interfaces label
information base (LIB). If the binding is in response to a previous
request (downstream allocation on demand), the stream to which the
binding applies and the MID of the binding must match that of the
corresponding request.
Any stream aggregation is performed downstream and is only noticeable
at the Merge LSR by multiple binding using the same label.
4.5.4 Operation of Intermediate LSRs
Intermediate LSRs are, in general, not merge capable. With regard to
the aggregated stream, the Intermediate LSR will only bind the same
label for multiple upstream streams (on the same incoming interface)
when the streams are assigned the same label by the next downstream
LSR.
As with the Merge LSR, all label requests are independent. For each
label request received on an incoming interface, a label request will
be generated and sent to the next hop according to the local LSR's
routing table. A unique MID is attached to each request sent
downstream for each unique tuple.
Label bindings received from downstream LSRs will contain a stream
(e.g., a route prefix), the assigned label and a MID. Flow
aggregation performed downstream is noticeable at the Intermediate
LSR by multiple streams using the same label and the same MID. It is
an error if the same label is used for two streams that do not have
the same MID.
When allocating a label for a new stream to an upstream LSR, the
Intermediate LSR may use a label in use for an existing stream (or
streams) on the same incoming interface if the following conditions
are met:
- The incoming MID of the new stream matches the incoming MID of
the existing stream(s)
Fredette, White, Andersson, Doolan [Page 13]
INTERNET-DRAFT Stream Aggregation Expires May 1998
- The new and existing streams use the same next hop combined with
condition 1, this implies that the outgoing MID of the new and
existing streams is the same
- The same label has been assigned by the downstream LSR for the
new and existing streams
If any of these conditions are not met, the Intermediate LSR must
allocate a new label for the upstream neighbor. If at a later time
the conditions are satisfied, the Intermediate LSR may release the
previous binding and bind the stream to the label of the exiting
stream(s).
4.5.5 Operation of Egress LSRs
The Egress LSR is responsible for determining whether multiple
streams may be aggregated. All streams that share the same MID are
eligible for aggregation.
Again, all label requests are independent. Each label request
received from upstream will contain an MID.
When allocating a label for a new stream to an upstream LSR, the
Egress LSR may use a label in use for an existing stream (or streams)
on the same incoming interface if the following condition is met:
- The incoming MID of the new stream matches the incoming MID of
the existing stream(s)
If this condition is not met, the Egress LSR must allocate a new
label for the upstream neighbor. If at a later time, the condition
is satisfied, the Egress LSR may release the previous binding and
bind the stream to the label of the exiting stream(s).
4.5.6 Reserved MID Values
It may be desirable to designate certain MID values or ranges of
values to be used for special circumstances.
4.5.6.1 NoAggregateValue
When setting up a point-to-point stream, it may be desirable for a
separate LSP to be setup that is not aggregated with any other
streams. A special MID=NoAggregateValue indicates to Egress LSRs that
a separate label should be allocated for this stream and not used for
Fredette, White, Andersson, Doolan [Page 14]
INTERNET-DRAFT Stream Aggregation Expires May 1998
any other stream. Possible uses include:
- RSVP streams
- Dedicated LSPs for control traffic
4.5.6.2 UnassignedMID
LSRs that allocate and distribute labels for streams before receiving
requests may use this MID value to indicate to the upstream LSR that
the associated label can be used for any MID value. The downstream
LSR assigning the label awaits an acknowledgment from upstream. A
positive acknowledgment must include a MID value associated with this
binding.
Using the UnassignedMID value allows upstream LSRs to make use of a
label before it is associated with a MID. It may shorten the setup
time as it does not require a full request to the downstream LSR and
then a response.
5. Conclusions
Four levels of aggregation and merging were described in this
document. It was shown that for non-merge capable LSRs, if left
unchecked, lack of aggregation can cause an explosion of the label
space.
Two viable alternatives were proposed:
1) Use a link-state routing protocol to decide at the ingress what
streams to aggregate (Section 4.2).
2) Use a merge ID (MID) in label binding requests (Section 4.5).
Furthermore, if option 2) is used, it only places an additional
burden on non-VC-merge capable switches.
6. References
[ARA] R. Coltun, J Heinanen, "The OSPF Address Resolution
Advertisement Option", Internet Draft, November 1997,
.
[HEIN] Heinanen, J., "Intra-area IP unicast among routers over
Fredette, White, Andersson, Doolan [Page 15]
INTERNET-DRAFT Stream Aggregation Expires May 1998
legacy ATM", Internet Draft, July 1997,
[MPLS-A] E. Rosen, A. Viswanathan, R. Callon, A Proposed
Architecture for MPLS, Internet Draft , August 1997.
[MPLS-F] R. Callon, P. Doolan, N. Feldman, A. Fredette, G. Swallow,
A. Viswanathan, A Framework for Multiprotocol Label
Switching, Internet Draft
<draft-ietf-mpls-framework-01.txt>, August 1997.
Author's Address
Andre N. Fredette
Bay Networks, Inc.
3 Federal St.
Billerica, MA 01821
Phone: (978) 916-8524
EMail: fredette@baynetworks.com
Christopher J. White
Bay Networks, Inc.
3 Federal St.
Billerica, MA 01821
Phone: (978) 916-4712
EMail: cwhite@baynetworks.com
Loa Andersson
Ericsson
Phone: + 46 8 719 52 67
email: loa.andersson@etx.ericsson.se
Paul Doolan
Ennovate Networks
330 Codman Hill Rd
Marlborough MA 01719
Phone: 978 263-2002
email: pdoolan@cisco.com
Fredette, White, Andersson, Doolan [Page 16]