Network Working Group Bruce Davie
Internet Draft Paul Doolan
Expiration Date: July 1997 Jeremy Lawrence
Keith McCloghrie
Yakov Rekhter
Eric Rosen
George Swallow
Cisco Systems, Inc.
January 1997
Use of Tag Switching With ATM
draft-davie-tag-switching-atm-01.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 ftp.is.co.za (Africa), nic.nordu.net (Europe),
munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
ftp.isi.edu (US West Coast).
Abstract
Davie, et al. [Page 1]
Internet Draft draft-davie-tag-switching-atm-01.txt January 1997
A tag switching architecture is described in [1]. Tag Switching
enables the use of ATM Switches as Tag Switching Routers. The ATM
Switches run network layer routing algorithms (such as OSPF, IS-IS,
etc.), and their data forwarding is based on the results of these
routing algorithms. No ATM-specific routing or addressing is needed.
This document describes how the tag switching architecture is applied
to ATM switches.
Contents
1 Introduction ........................................... 2
2 Definitions ............................................ 3
3 Special Characteristics of ATM Switches ................ 3
4 Tag Switching Control Component for ATM ................ 4
5 Hybrid Switches (Ships in the Night) ................... 4
6 Use of VPI/VCIs ....................................... 5
7 Tag Allocation and Maintenance Procedures .............. 5
7.1 Edge TSR Behavior ...................................... 5
7.2 Conventional ATM Switches (non-VC-merge) ............... 6
7.3 VC-merge-capable ATM Switches .......................... 8
7.4 Efficient use of tag space ............................. 9
8 Encapsulation .......................................... 10
9 Security Considerations ................................ 10
10 Intellectual Property Considerations ................... 10
11 References ............................................. 11
12 Acknowledgments ........................................ 11
13 Authors' Addresses ..................................... 11
1. Introduction
A tag switching architecture is described in [1]. It is possible to
use ATM switches as tag switching routers. Such ATM switches run
network layer routing algorithms (such as OSPF, IS-IS, etc.), and
their forwarding is based on the results of these routing algorithms.
No ATM-specific routing or addressing is needed.
When an ATM switch is used for tag switching, the tag on which
forwarding decisions are based is carried in the VCI and/or VPI
fields. (It is possible to carry multiple tags in the VCI and/or VPI
fields, but the scope of this document is restricted to the case of a
single tag.)
Davie, et al. [Page 2]
Internet Draft draft-davie-tag-switching-atm-01.txt January 1997
The characteristics of ATM switches require some specialized
procedures and conventions to support tag switching. This document
describes those aspects of tag switching which are specific to ATM.
2. Definitions
A Tag Switching Router (TSR) is a device which implements the tag
switching control and forwarding components described in [1].
A tag switching controlled ATM (TC-ATM) interface is an ATM interface
controlled by the tag switching control component. Packets traversing
such an interface carry tags in the VCI and/or VPI field.
An ATM-TSR is a TSR with a number of TC-ATM interfaces which forwards
cells between these interfaces using tags carried in the VCI and/or
VPI field.
A frame-based TSR is a TSR which forwards complete frames between its
interfaces. Note that such a TSR may have zero, one or more TC-ATM
interfaces.
An ATM-TSR cloud is a set of ATM-TSRs which are mutually
interconnected by TC-ATM interfaces.
The Edge Set of an ATM-TSR cloud is the set of frame-based TSRs which
are connected to the cloud by TC-ATM interfaces.
VC-merge is the process by which a switch receives cells on several
incoming VCIs and transmits them on a single outgoing VCI without
causing the cells of different AAL5 PDUs to become interleaved.
3. Special Characteristics of ATM Switches
While the tag switching architecture permits considerable flexibility
in TSR implementation, an ATM-TSR is constrained by the capabilities
of the (possibly pre-existing) hardware and the restrictions on such
matters as cell format imposed by ATM standards. Because of these
constraints, some special procedures are required for ATM-TSRs.
Some of the key features of ATM switches that affects their behavior
as TSRs are:
- the label swapping function is performed on fields (the VCI
and/or VPI) in the cell header; this dictates the size and
placement of the tag(s) in a packet.
Davie, et al. [Page 3]
Internet Draft draft-davie-tag-switching-atm-01.txt January 1997
- multipoint-to-point and multipoint-to-multipoint VCs are
generally not supported. This means that most switches cannot
support `VC-merge' as defined above.
- there is generally no capability to perform a `TTL-decrement'
function as is performed on IP headers in routers.
This document describes ways of applying tag switching to ATM
switches which work within these constraints.
4. Tag Switching Control Component for ATM
To support tag switching an ATM switch must implement the control
component of tag switching. This consists primarily of tag allocation
and maintenance procedures. Tag binding information is communicated
by several mechanisms, notably the Tag Distribution Protocol (TDP)
[2].
Since the tag switching control component uses information learned
directly from network layer routing protocols, this implies that the
switch must participate as a peer in these protocols (e.g., OSPF,
IS-IS).
In some cases, TSRs make use of other protocols (e.g. RSVP, PIM, BGP)
to distribute tag bindings. In these cases, an ATM TSR would need to
participate in these protocols.
Support of tag switching on an ATM switch does not require the switch
to support the ATM control component defined by the ITU and ATM Forum
(e.g., UNI, PNNI). An ATM-TSR may optionally respond to OAM cells.
5. Hybrid Switches (Ships in the Night)
The existence of the tag switching control component on an ATM switch
does not preclude the ability to support the ATM control component
defined by the ITU and ATM Forum on the same switch and the same
interfaces. The two control components, tag switching and the
ITU/ATM Forum defined, would operate independently.
Definition of how such a device operates is beyond the scope of this
document. However, only a small amount of information needs to be
consistent between the two control components, such as the portions
of the VPI/VCI space which are available to each component.
Davie, et al. [Page 4]
Internet Draft draft-davie-tag-switching-atm-01.txt January 1997
6. Use of VPI/VCIs
Tag switching is accomplished by associating tags with routes and
using the tag value to forward packets, including determining the
value of any replacement tag. See [1] for further details. In an
ATM-TSR, the tag is carried in the VPI and/or VCI field. Just as in
conventional ATM, for a cell arriving at an interface, the VPI/VCI is
looked up, replaced, and the cell is switched.
ATM-TSRs may be connected by ATM virtual paths to enable
interconnection of ATM-TSRs over a cloud of conventional ATM
switches. In this case, the tag is carried in the VCI field.
For two connected ATM-TSRs, a connection must be available for TDP.
The default is for this connection to be on VPI 0, VCI 32. For ATM-
TSRs connected by a VPI of value x, the default for the TDP
connection is VPI x, VCI 32. Additionally, for all VPI values, VCIs 0
- 32 are not used as tags.
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 always communicated through TDP.
If more than one VPI is used for tag switching, the allowable range
of VCIs may be different for each VPI, and each range is communicated
through TDP.
7. Tag Allocation and Maintenance Procedures
ATM-TSRs use the downstream-on-demand allocation mechanism described
in [1]. The procedures for tag allocation depend on whether the
switches support VC-merge or not. We therefore describe the two
scenarios in turn. We begin by describing the behavior of members of
the Edge Set of an ATM-TSR cloud; these edge TSRs are not themselves
ATM-TSRs, and their behavior is the same whether the cloud contains
VC-merge capables TSRs or not.
7.1. Edge TSR Behavior
Consider a member of the Edge Set of an ATM-TSR cloud. Assume that,
as a result of its routing calculations, it selects an ATM-TSR as the
next hop of a certain route, and that the next hop is reachable via a
TC-ATM interface. The Edge TSR uses TDP's BIND_REQUEST to request a
tag binding from the next hop. The hop count field in the request is
set to 1. Once the Edge TSR receives the tag binding information,
Davie, et al. [Page 5]
Internet Draft draft-davie-tag-switching-atm-01.txt January 1997
the tag is used as an outgoing tag. The binding received by the edge
TSR may contain a hop count, which represents the number of hops a
packet will take to cross the ATM-TSR cloud when using this tag. The
edge TSR may either
- use this hop count to decrement the TTL of packets before
transmitting them over the cloud
- decrement the TTL of packets by one before transmitting them
over the cloud.
The choice between these two options should be made based on local
configuration.
When a member of the Edge Set of the ATM-TSR cloud receives a tag
binding request from an ATM-TSR, it allocates a tag, creates a new
entry in its Tag Information Base (TIB), places that tag in the
incoming tag component of the entry, and returns (via TDP) a binding
containing the allocated tag back to the peer that originated the
request. It sets the hop count in the binding to 1.
When a routing calculation causes an Edge TSR to change the next hop
for a route, and the former next hop was in the ATM-TSR cloud, the
Edge TSR should notify the former next hop (via TDP) that the tag
binding associated with the route is no longer needed.
7.2. Conventional ATM Switches (non-VC-merge)
When an ATM-TSR receives (via TDP) a tag binding request for a
certain route from a peer connected to the ATM-TSR over a TC-ATM
interface, the ATM-TSR takes the following actions:
- it allocates a tag, creates a new entry in its Tag Information
Base (TIB), and places that tag in the incoming tag component of
the entry;
- it requests (via TDP) a tag binding from the next hop for that
route;
- it returns (via TDP) a binding containing the allocated
incoming tag back to the peer that originated the request.
Davie, et al. [Page 6]
Internet Draft draft-davie-tag-switching-atm-01.txt January 1997
The hop count field in the request that the ATM-TSR sends (to the
next hop TSR) is set to the hop count field in the request that it
received from the upstream TSR plus one. Once the ATM-TSR receives
the binding from the next hop, it places the tag from the binding
into the outgoing tag component of the TIB entry.
The ATM-TSR may choose to wait for the request to be satisfied from
downstream before returning the binding upstream (a "conservative"
approach). In this case, the ATM-TSR increments the hop count it
received from downstream and uses this value in the binding it
returns upstream. If the value of the hop count equals MAX_HOP_COUNT
the ATM-TSR should notify the upstream neighbor that it could not
satisfy the binding request.
Alternatively, the ATM-TSR may return the binding upstream without
waiting for a binding from downstream (an "optimistic" approach). In
this case, it uses a reserved value for hop count in the binding,
indicating that it is unknown. The correct value for hop count will
be returned later, as described below.
Since both the conservative and the optimistic approach has
advantages and disadvantages, this is left as an implementation
choice.
Note that an ATM-TSR, or a member of the edge set of an ATM-TSR
cloud, may receive multiple binding requests for the same route from
the same ATM-TSR. It must generate a new binding for each request
(assuming adequate resources to do so), and retain any existing
binding(s). For each request received, an ATM-TSR should also
generate a new binding request toward the next hop for the route.
When a routing calculation causes an ATM-TSR to change the next hop
for a route, the ATM-TSR should notify the former next hop (via TDP)
that the tag binding associated with the route is no longer needed.
When a TSR receives a notification that a particular tag binding is
no longer needed, the TSR may deallocate the tag associated with the
binding, and destroy the binding. In the case where an ATM-TSR
receives such notification and destroys the binding, it should notify
the next hop for the route that the tag binding is no longer needed.
If a TSR does not destroy the binding, it may re-use the binding only
if it receives a request for the same route with the same hop count
as the request that originally caused the binding to be created.
When a route changes, the tag bindings are re-established from the
point where the route diverges from the previous route. TSRs
upstream of that point are (with one exception, noted below)
oblivious to the change. Whenever a TSR changes its next hop for a
Davie, et al. [Page 7]
Internet Draft draft-davie-tag-switching-atm-01.txt January 1997
particular route, if the new next hop is an ATM-TSR or a member of
the edge set reachable via a TC-ATM interface, then for each entry in
its TIB associated with the route the TSR should request (via TDP) a
binding from the new next hop.
When an ATM-TSR receives a tag binding from a downstream neighbor, it
may already have provided a corresponding tag binding for this route
to an upstream neighbor, either because it is operating
optimistically or because the new binding from downstream is the
result of a routing change. In this case, it should extract the hop
count from the new binding and increment it by one. If the new hop
count is different from that which was previously conveyed to the
upstream neighbor (including the case where the upstream neighbor was
given the value `unknown') the ATM-TSR must notify the upstream
neighbor of the change. Each ATM-TSR in turn increments the hop count
and passes it upstream until it reaches the ingress Edge TSR. If at
any point the value of the hop count equals MAX_HOP_COUNT, the ATM-
TSR should withdraw the binding from the upstream neighbor.
Whenever an ATM-TSR originates a tag binding request to its next hop
TSR as a result of receiving a tag binding request from another
(upstream) TSR, and the request to the next hop TSR is not satisfied,
the ATM-TSR should destroy the binding created in response to the
received request, and notify the requester (via TDP).
If an ATM-TSR receives a binding request containing a hop count that
equals MAX_HOP_COUNT, no binding should be established and an error
message should be returned to the requester.
When a TSR determines that it has lost its TDP session with another
TSR, the following actions are taken. Any binding information
learned via this connection must be discarded. For any tag bindings
that were created as a result of receiving tag binding requests from
the peer, the TSR may destroy these bindings (and deallocate tags
associated with these binding).
7.3. VC-merge-capable ATM Switches
Relatively minor changes are needed to accommodate ATM-TSRs which
support VC-merge. The primary difference is that a VC-merge-capable
ATM-TSR needs only one outgoing tag per route, even if multiple
requests for tag bindings to that route are received from upstream
neighbors.
When a VC-merge-capable ATM-TSR receives a binding request from an
upstream TSR for a certain route, and it does not already have an
Davie, et al. [Page 8]
Internet Draft draft-davie-tag-switching-atm-01.txt January 1997
outgoing tag binding for that route, it issues a bind request to its
next hop just as before. If, however, it already has an outgoing tag
binding for that route, it does not need to issue a downstream
binding request. Instead, it creates a new TIB entry, allocates an
incoming tag for that entry and returns that tag in a binding to the
upstream requester, and uses the existing outgoing tag for the
outgoing tag entry in the TIB. It also takes the hop count that was
provided with the tag binding it received from downstream, increments
it by one, and uses this value in the binding that it sends to the
upstream requester.
Note that, just like conventional ATM-TSRs and members of the edge
set of the ATM-TSR cloud, a VC-merge-capable ATM-TSR must issue a new
binding every time it receives a request from upstream, since there
may be switches upstream which do not support VC-merge. However, it
only needs to issue a corresponding binding request downstream if it
does not already have a tag binding for the appropriate route.
When a change in the routing table of a VC-merge-capable ATM-TSR
causes it to select a new next hop for one of its routes, it releases
the binding for that route from the former next hop and requests a
new binding from the new next hop. If the new binding contains a hop
count that differs from that which was received in the old binding,
then the ATM-TSR must take the new hop count, increment it by one,
and notify any upstream neighbors who have tag bindings for this
route of the new value. Just as with conventional ATM-TSRs, this
enables the new hop count to propagate back towards the ingress of
the ATM-TSR cloud. If at any point the hop count reaches
MAX_HOP_COUNT, then the tag bindings for this route must be withdrawn
from all upstream neighbors to whom a binding was previously
provided. This ensures that any loops caused by routing transients
will be detected and broken.
7.4. Efficient use of tag space
The above discussion assumes that an edge TSR will request one tag
for each prefix in its routing table that has a next hop in the ATM-
TSR cloud. In fact, it is possible to significantly reduce the number
of tags needed by having the edge TSR request instead one tag for
several routes. Use of many-to-one mappings between routes (address
prefixes) and tags using the notion of Forwarding Equivalence Classes
(as described in [1]) provides a mechanism to conserve the number of
tags.
Davie, et al. [Page 9]
Internet Draft draft-davie-tag-switching-atm-01.txt January 1997
8. Encapsulation
By default, all tagged packets should be transmitted with the generic
tag encapsulation, as defined in [3]. Since the value at the top of
the tag stack is determined from the VCI and/or VPI fields, the
generic encapsulation contains n-1 tags for a tag stack of depth n.
This means that for one level of tags the generic encapsulation
consists of a tag leader only.
For systems which are using only one level of tagging, TDP may be
used to negotiate null encapsulation. This negotiation is done once
at TDP open and applies to all VPI/VCI values used as tags. In this
case, IP packets are carried directly inside AAL5 frames, as in the
null encapsulation of RFC 1483.
The initial TDP connection, described in Section 5, uses the LLC/SNAP
encapsulation, as defined in Section 4.1 of RFC1483. This same VCI
(with the LLC/SNAP encapsulation) may be used to exchange Network
Layer routing information as well.
TDP may be used to advertise additional VPI/VCIs to carry control
information or non-tagged packets. These may use either the null
encapsulation, as defined in Section 5.1 of RFC1483, or the LLC/SNAP
encapsulation, as defined in Section 4.1 of RFC1483.
9. Security Considerations
Security considerations are not addressed in this document.
10. Intellectual Property Considerations
Cisco Systems may seek patent or other intellectual property
protection for some or all of the technologies disclosed in this
document. If any standards arising from this document are or become
protected by one or more patents assigned to Cisco Systems, Cisco
intends to disclose those patents and license them under openly
specified and non-discriminatory terms, for no fee.
Davie, et al. [Page 10]
Internet Draft draft-davie-tag-switching-atm-01.txt January 1997
11. References
[1] Rekhter, Y. et al. Tag Switching Architecture Overview, Internet
Draft, draft-rekhter-tagswitch-arch-00.txt, Jan. 1997.
[2] Doolan, P. et al. Tag Distribution Protocol, Internet Draft,
draft-doolan-tdp-spec-00.txt, Sept. 1996.
[3] Rosen, E. et al. Tag Switching: Tag Stack Encodings, Internet
Draft, Oct. 1996.
12. Acknowledgments
Significant contributions to this work have been made by Anthony
Alles, Fred Baker, Dino Farinacci, Guy Fedorkow, Arthur Lin, Morgan
Littlewood and Dan Tappan.
13. Authors' Addresses
Bruce Davie
Cisco Systems, Inc.
250 Apollo Drive
Chelmsford, MA, 01824
E-mail: bsd@cisco.com
Paul Doolan
Cisco Systems, Inc.
250 Apollo Drive
Chelmsford, MA, 01824
E-mail: pdoolan@cisco.com
Jeremy Lawrence
Cisco Systems, Inc.
1400 Parkmoor Ave.
San Jose, CA, 95126
E-mail: jlawrenc@cisco.com
Davie, et al. [Page 11]
Internet Draft draft-davie-tag-switching-atm-01.txt January 1997
Keith McCloghrie
Cisco Systems, Inc.
170 Tasman Drive
San Jose, CA, 95134
E-mail: kzm@cisco.com
Yakov Rekhter
Cisco Systems, Inc.
170 Tasman Drive
San Jose, CA, 95134
E-mail: yakov@cisco.com
Eric Rosen
Cisco Systems, Inc.
250 Apollo Drive
Chelmsford, MA, 01824
E-mail: erosen@cisco.com
George Swallow
Cisco Systems, Inc.
250 Apollo Drive
Chelmsford, MA, 01824
E-mail: swallow@cisco.com
Davie, et al. [Page 12]