Internet-Draft Nancy Feldman
Expiration Date: August 1999 IBM
Bilel Jamoussi
Nortel Networks
Sridhar Komandur
Ascend Communications
Arun Viswanathan
Lucent Technologies
Tom Worster
GDC
February 1999
MPLS using ATM VP Switching
<draft-feldman-mpls-atmvp-00.txt>
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other
documents at any time. It is inappropriate to use Internet-
Drafts as reference material or to cite them other than as "work
in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Feldman et al Expires August 1999 [Page 1]
Internet Draft MPLS Using ATM VP Switching February 1999
Abstract
The MPLS Architecture [ARCH] discusses the way in which ATM
switches may be used as Label Switching Routers. The MPLS ATM VC
switching document [ATMVC] details the way in which ATM-LSRs are
used, specifically in the presence of non-merge and VC-merge
capable switches. This document is a companion document to
[ATMVC]; it extends the ATM procedures for the support of VP-
switching on ATM-LSRs. It is assumed the reader is familiar with
the contents of [ATMVC].
1. Introduction
The MPLS Architecture [ARCH] discusses the way in which ATM
switches may be used as Label Switching Routers. The MPLS ATM VC
Switching [ATMVC] document details the way in which ATM-LSRs are
used, specifically in the presence of non-merge and VC-merge
capable switches. This document extends the ATM procedures in
[ATMVC] for supporting the distribution of labels as VPI values.
This document assumes the reader is familiar with the ATM terms
and procedures as defined in [ATMVC].
To connect all ingresses to all the egresses in a switched network
requires O(n-squared) Label Switched Paths (LSPs). In order to
scale to O(n) (rather than O(n-squared)), MPLS makes use of the
concept of stream merge. This allows the creation of multipoint-
to-point LSP trees, in which multiple incoming streams with the
same FEC may be combined into a single outgoing stream. To merge
multiple incoming VCs to a single outgoing VC requires that ATM
switching hardware have the capability of preventing cell
interleaving [ARCH]. However, much of the legacy ATM switching
hardware cannot support VC merging.
Several legacy ATM switches support what is known as "VP-
switching". In ATM switches that support VP-switching, it is
possible to create connections (cross-connects) that use only the
VPI field in the ATM header to switch cells, and the VCI field is
not used in the lookup that determines the outgoing label and/or
the outgoing interface. This capability is termed as VP-merge.
VP-merge is the process by which a switch receives cells on
several incoming VPIs and transmits them on a single outgoing VPI.
In this merging style, each ingress LSR in a merged multipoint-to-
point LSP use a unique VCI value when injecting packets (cells)
into the multipoint-to-point connection. At the merging nodes,
where multiple upstream VPs are merged into a single outgoing VP,
cells from different sources get interleaved, but the unique VCI
values used by the sources help to maintain the identity of all
PDUs so that they may be properly reassembled at the egress node.
Feldman et al Expires August 1999 [Page 2]
Internet Draft MPLS Using ATM VP Switching February 1999
Another use of VP-switching is in label stacking [LBLSTK]. The
VPI/VCI label pair in ATM can be likened to be two separate
labels, such that, the lower label is VCI and the top label is
VPI. The cells are switched based on the top label (VPI; that is
VP-switching), till the top label is popped (that is, the VP
switching ends), and the cells are switched based on the bottom
label (that is VCI; or VPI/VCI together).
Yet another use of VP-switching is in tunneling via ATM networks
that aren't MPLS capable. This procedure is described in [ATMVC],
and is repeated in this document for completeness.
This document provides procedures for exchanging VPIs as labels to
create LSPs for use in the situations described above.
2. Specification of Requirements
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL"
in this document are to be interpreted as described in RFC 2119
[RFC2119].
3. Definitions
The following definitions are from [ATMVC], with appropriate
modifications for the inclusion of VP-switching:
A Label Switching Router (LSR) is a device which implements the
label switching control and forwarding components described in
[ARCH].
A label switching controlled ATM (LC-ATM) interface is an ATM
interface controlled by the label switching control component.
When a packet traversing such an interface is received, it is
treated as a labeled packet. The packet
--0__=HMHuhIMHG1DD2XKsmZDmsmAiX7UaOk9QxAH1mQKJSw69tdNnfPmPkdrg
Content-type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
=C6s top label is inferred
from the contents of the VCI field only, the VPI field only, or
the combined contents of the VPI and VCI fields. Any two LDP
peers which are connected via an LC-ATM interface will use LDP
negotiations to determine which of these cases is applicable to
that interface. Moreover, only one of the above cases can be
active at a time on an LC-ATM interface.
An ATM-LSR is a LSR with a number of LC-ATM interfaces which
forwards cells between these interfaces using labels carried in
the VCI, VPI, or VPI/VCI field.
Feldman et al Expires August 1999 [Page 3]
Internet Draft MPLS Using ATM VP Switching February 1999
4. Use of VPI/VCIs
Label switching is accomplished by associating labels with
Forwarding Equivalence Classes, and using the label value to
forward packets. An ATM-LSR that is performing VP switching
carries the label in the VPI field.
We say that two LSRs are "directly connected" over an LC-ATM
interface if all cells transmitted out that interface by one LSR
will reach the other, and there are no ATM switches between the
two LSRs.
When two LSRs are directly connected via an LC-ATM interface, they
jointly control the allocation of VPIs/VCIs on the interface
connecting them. They may agree to use the VCI, VPI, or VPI/VCI
field to encode a single label.
The default VPI/VCI value for the non-MPLS connection is VPI 0,
VCI 32. Other values can be configured, as long as both parties
are aware of the configured value.
The VPI value 0 MUST NOT be used with VP switching.
Any VCI value in the range 0-65535 inclusive MAY be used as a
label with VP switching.
With the exception of these reserved values, the VPI/VCI values
used in the two directions of the link MAY be treated as
independent spaces.
The allowable ranges of VPIs and VCIs are communicated through
LDP.
4.1. VP-merge Connection
Directly connected ATM-LSRs may use the VPI field to carry the
MPLS label. The choice of this mode of operation and the valid
VPI ranges must be negotiated via LDP. However, the VPI value of
0 MUST NOT be used as an MPLS label indicator. In addition, if
two LDP peers using VP-merge are connected via a LC-ATM interface,
the VPI value 0 is reserved for non-MPLS connections. This non-
MPLS connection is used to carry LDP packets between the two
peers, and MAY also be used (but is not required to be used) for
other unlabeled packets (such as OSPF packets, etc.). The
LLC/SNAP encapsulation of RFC 1483 [RFC1483] MUST be used on the
non-MPLS connection.
4.2. Connections via an ATM Virtual Path
Feldman et al Expires August 1999 [Page 4]
Internet Draft MPLS Using ATM VP Switching February 1999
Sometimes it can be useful to treat two LSRs as adjacent (in some
LSP) across an LC-ATM interface, even though the connection
between them is made through an ATM "cloud" via an ATM Virtual
Path. In this case, the VPI field is not available to MPLS, and
the label MUST be encoded entirely within the VCI field.
In this case, the default VCI value of the non-MPLS connection
between the LSRs is 32. The VPI is set to whatever is required to
make use of the Virtual Path.
A VPI/VCI value whose VCI part is in the range 0-32 inclusive MUST
NOT be used as the encoding of a label.
With the exception of these reserved values, the VPI/VCI values
used in the two directions of the link MAY be treated as
independent spaces.
The allowable ranges of VPI/VCIs are communicated through LDP. If
more than one VPI is used for label switching, the allowable range
of VCIs may be different for each VPI, and each range is
communicated through LDP.
5. Label Distribution and Maintenance Procedures
In general, an ATM-LSR configured for VP-merge MAY use either
"ordered control" OR "independent control" label distribution, as
well as "unsolicited downstream" OR "downstream-on-demand" label
allocation. (see [ARCH, LDP]).
Due to the limited number of VPs that may be created in a VP-merge
environment, there may be a shortage of VPs if the number of IP-
prefixes in the domain is greater than the maximum number of VPs
available (as determined by the allocated VPI bits). This can be
mitigated in the following ways:
- All ATM-LSRs in a domain may be configured for BGP or link st=
ate
egress aggregation. In this case, a single LSP is sustained =
for
all prefixes which share a common egress point, thereby
significantly reducing the number of necessary VPs.
- All ATM-LSRs in a domain may be configured for "ordered contr=
ol"
label distribution and "unsolicited downstream" label allocat=
ion.
This allows the egress nodes to control which LSPs are create=
d in
the domain, thereby permitting a limited VP space to be alloc=
ated
wisely.
- All ATM-LSRs in a domain SHOULD be configured for Conservativ=
e
Label Retention (see [ARCH]). This eliminates the use and
maintenance of unnecessary labels.
Feldman et al Expires August 1999 [Page 5]
Internet Draft MPLS Using ATM VP Switching February 1999
5.1. VP-merge-capable ATM Switches
VP-merge is the process by which a switch receives cells on
several incoming VPIs and transmits them on a single outgoing VPI.
The ATM-LSRs neither looks into the VCI field for switching the
cells nor modify its content on the outgoing interface. VP-merge
MAY be used only when the ENTIRE ATM-LSR domain is capable of VP-
merge. If the entire ATM-LSR domain is not capable of VP-merge,
then one of the applicable procedures described for either non-
merge or VC-merge must be used (see [ATMVC]).
To use VP-merge in an ATM-LSR domain, each of the LSRs in the Edge
Set MUST be assigned a unique VCI value. VP-Merge capable Ingress
Edge LSRs MUST provide a means of configuring a unique VCI value.
While other unique VCI allocation mechanisms may be possible, a
description of such mechanisms is outside the scope of this
document. The egress must be cognizant of the VCI ranges
allocated at the ingresses, so that it aware of the VCI values it
must reassemble on.
5.2. Limitations of VP-merge
VP-merge, besides its usefulness, comes with several limitations.
These limitations must be carefully considered before deploying a
network that uses VP-merge.
All ATM-LSRs in an ATM-LSR domain must be capable of VP-merge.
That is, VP-merge does not interoperate with VC-merge or non-merge
ATM-LSRs.
- There should be sufficient number of VPI bits supported by the
ATM-LSRs in use. If hybrid mode (ships in the night mode) is u=
sed,
some LC-ATM can have only a maximum of 8-bits for VPI.
- LSRs in an ATM-LSR domain using VP-merge must be directly
connected. That is, the LC-ATM interface of a VP-merge ATM-LSR=
must
directly connect to another VP-merge ATM-LSR without any
intervening
ATM switches. Therefore, two VP-merge domains cannot be connec=
ted
via a public ATM network except through the IP layer.
- To use VP-merge, each Ingress Edge ATM-LSR MUST be assigned a
unique VCI value. Currently, the only specified method to assi=
gn
these VCI values is via configuration.
6. Egress aggregation with VP-merge
Feldman et al Expires August 1999 [Page 6]
Internet Draft MPLS Using ATM VP Switching February 1999
Aggregation is the concept of merging multiple FECs with a common
destination into a single FEC, sharing the same LSP. Aggregation
may be achieved through information available in BGP or link-state
routing protocols, where a set of IP destinations are known to
traverse the same IP path to a common egress point. However, some
route protocols, such as RIP, do not provide knowledge of the
egress point. In these situations, if egress aggregation is
desired, the egress LSR must be configured to advertise the same
label for all (or a set of) IP prefixes reachable through that
LSR.
In the case of aggregation via BGP or a link-state routing
protocol, the egress node is advertised in the FEC TLV "IP Prefix"
with a mask of /32 [LDP]. In the other form of egress
aggreg=
ation, hence referred to as "generic" egress aggregation,
each prefix may be advertised individually as a separate FEC via
the TLV "IP Prefix", yet given the same label. However, when VP-
merging is used, this latter form of generic egress aggregation
could cause cell interleaving problems if each destination does
not follow the exact same IP-path through the network. Thus, an
LSR desiring generic egress aggregation must use the FEC
Aggregation-List TLV (see section 6.1).
In the Aggregation-List TLV, each set of IP prefixes which are to
share a common LSP are distinguished by a unique identifier. The
aggregating egress LSR transmits a Mapping Message with an
Aggregation-List TLV containing a unique identifier, commonly the
router-id of the egress LSR, as well as a list of IP prefixes that
are to share the same label (as found in the Label TLV; see
[LDP]). Each LSR which receives the Aggregation-List from a peer
verifies in the Forwarding Information Base (FIB) that each IP
prefix in the given list uses that peer as its nexthop; any IP
prefix which fails the test MUST be pruned off of the aggregation
list. The LSR then forwards the remaining list to its upstream
neighbors.
The Aggregation-List is tightly coupled with its peer and assigned
label. Once it has been received and accepted, any further
Mapping Message containing that aggregation identifier MUST be
received from the same peer, and MUST contain the same label. An
LSR MUST NOT accept an Aggregation-List with the same unique
identifier from any other peer, or with a different label, until
the original Aggregation-List has been cancelled via the Withdraw
Message [LDP]. By constraining the Aggregation-List to associate
with only one peer and label, it guarantees that all IP prefixes
to a common egress LSR will share the same LSP, and thus avoids
any cell interleaving problems.
Note that a Withdraw Message containing an Aggregation-List TLV
with zero prefixes is treated as a "wildcard", and removes ALL
Feldman et al Expires August 1999 [Page 7]
Internet Draft MPLS Using ATM VP Switching February 1999
prefixes associated with that aggregation list.
Generic egress aggregation MUST be used in conjunction with
"ordered" label distribution and SHOULD be used with "unsolicited
downstream" label allocation.
6.1. Aggregation-List Encoding
The FEC TLV is defined in [LDP]. It is composed of FEC element
types. The following element is used for the Aggregation List:
FEC Element Type Value
type name
Aggregation-List 0x04 Variable
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Agg-List (4) | Address Family | PreCount |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Aggregate Unique-Id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix Len | Prefix ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
.... (variable length)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+............................
Address Family
Two octet quantity containing a value from ADDRESS FAMILY
NUMBERS in [RFC1700] that encodes the address family for
the address prefix in the Prefix field.
PreCount
One octet number of address prefixes in this TLV, which
comprise the set of prefixes that are to be aggregated
together.
Aggregate Unique-Id
Four octet unique identifier assigned by the LSR
initiating the aggregation. This value MAY be the
originating LSRs unique router-id.
Prefix Len
Feldman et al Expires August 1999 [Page 8]
Internet Draft MPLS Using ATM VP Switching February 1999
One octet unsigned integer containing the length in bits
of the address prefix that follows.
Prefix
A variable length field containing an address prefix whose
length, in bits, was specified in the previous (Prefix
Len) field. The last prefix in this TLV must be padded to
a byte boundary.
7. Stacking
ATM switches typically support the use of the VPI and VCI fields
as a two level hierarchy. This capability may be used to support
label stacking in MPLS. In a VCI/VPI label stacking scenario,
aggregation happens as LSPs in VCs in the outer cloud are
multiplexed onto VPs to be sent across the inner cloud. When a VP
reaches its egress from the inner cloud it is demultiplexed and
the VC LSPs are segregated for distribution to their destinations.
In this stacking model the VP LSPs are point-to-point and VC merge
may be deployed in the outer cloud.
Procedures for using VP switching in this mode will be discussed
in a future revision.
8. Encapsulation
The MPLS encapsulation to be used when sending labeled packets to
or from ATM-LSRs is as specified in [ATMVC].
9. Optional Loop Detection: Distributing Path Vectors
The optional loop detection procedures are as specified in
[ATMVC]. Rules specific to VC-merge are also applicable to VP-
merge.
10. TTL Manipulation
The TTL handling procedures are as specified in [ATMVC].
11. Security Considerations
The use of the procedures and encapsulations specified in this
document does not have any security impact other than that which
may generally be present in the use of any MPLS procedures or
Feldman et al Expires August 1999 [Page 9]
Internet Draft MPLS Using ATM VP Switching February 1999
encapsulations (see [ARCH]).
12. Intellectual Property Considerations
The IETF has been notified of intellectual property rights claimed
in regard to some or all of the specification contained in this
document. For more information consult the online list of claimed
rights.
13. Acknowledgements
This document shamelessly borrows from the ATM companion document
[ATMVC].
14. References
[ARCH] E. Rosen, A. Viswanathan, R. Callon, "Multiprotocol
Label Switching Architecture", Work in Progress,
February 1999.
[ATMVC] B. Davie, J. Lawrence, K. McCloghrie, Y. Rekhter, E.
Rosen, G. Swallow, P. Doolan, "MPLS using ATM VC
Switching", Work in Progress, November, 1998.
[LBLSTK] E. Rosen, Y. Rekhter, D. Tappan, D. Farinacci, G.
Fedorkow, T. Li, A. Conta, "MPLS Label Stack Encoding",
Work in Progress, September 1998.
[LDP] L. Anderson, P. Doolan, N. Feldman, A. Fredette, B.
Thomas, "LDP Specification", Work in Progress, January
1999.
[RFC1483] J. Heinanen, "Multiprotocol Encapsulation over ATM
Adaptation Layer 5", RFC 1483, Telecom Finland, July
1993.
[RFC1700] J. Reynolds, J.Postel, "Assigned Numbers", October
1994.
[RFC2119] S. Bradner, "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, BCP 14, March 1997.
15. Authors' Addresses
Nancy Feldman
IBM Corp.
Feldman et al Expires August 1999 [Page 10]
Internet Draft MPLS Using ATM VP Switching February 1999
30 Saw Mill River Rd.
Hawthorne, NY 10532
Phone: +1 914-784-3254
Email: nkf@us.ibm.com
Bilel Jamoussi
Nortel Networks
P O Box 3511 Station C
Ottawa, ON K1Y 4H7
Canada
Phone: +1 613 765-4814
Email: jamoussi@NortelNetworks.com
Sridhar Komandur
Ascend Communications
1 Robbins Rd
Westford, MA 01886
Phone: +1 978-952-7164
Email: sridhar.komandur@ascend.com
Arun Viswanathan
Lucent Technologies
101 Crawford Cornet Rd.
Holmdel, NJ 07733
Phone: +1 732-332-5163
Email: arunv@lucent.com
Tom Worster
GDC
199 W Newton St.
Boston, MA 02116 USA
Phone: +1 617 247 2624
Email: tom.worster@gdc.com
Feldman et al Expires August 1999 [Page 11]