Internet Info 1997 December/Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso/drafts/draft_n_r/draft-ohba-tagsw-vs-csr-00.txt

Text File | 1997-04-25 | 16KB | 376 lines

Multi-Protocol Label Switching WG                          Yoshihiro Ohba
Internet Draft                                             Toshiba
Expiration Date: October 1997
                                                           Hiroshi Esaki
                                                           Toshiba

                                                           Yasuhiro Katsube
                                                           Toshiba

                                                           April  1997


    Comparison of Tag Switching and Cell Switch Router
                draft-ohba-tagsw-vs-csr-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 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

Tag Switching and Cell Switch Router are layer integration
technologies between L2 and L3 to provide high-speed cut-through
mechanisms for L3 packet transfer by mapping between L3 and L2
datagram labels. TDP and FANP, used in Tag Switching and Cell Switch
Router, respectively, are protocols that notify the mapping
information between peer routers.  Although the objectives of both
technologies are the same, there are several differences in methods
for achieving the objective. This memo compares the two technologies
and discusses how to merge them.

1. Tag Switching

In Tag Switching, the mapping is called binding, and the binding is
uniquely identified by 32-bit fixed length index called tag. Tags are
allocated based mainly on destination address to support
destination-based routing (of course Tag Switching can support other
allocation policies). A destination-based binding is created when the
routing protocol running on the TSR creates a new routing table entry.
This type of allocation is called "control-traffic-driven."

As for tag allocation, Tag Switching allows three modes: downstream
tag allocation, downstream tag allocation on demand, and upstream tag
allocation. Downstream tag allocation on demand is currently defined
for supporting ATM. Hereafter we focus on downstream on demand for the
purpose of discussion on tag management over ATM. See [1] for other
modes.

Tag Switching uses two methods for advertising the mapping between L2
and L3 labels. One method is using existing protocol packets, i.e.,
tags are carried in the protocol messages such as BGP, PIM, and RSVP
[2] messages. The other method is using Tag Distribution Protocol
(TDP) [3] which is the specialized protocol for distributing tags. TDP
is used where the former method is not efficient (e.g., an OSPF area).

TDP runs between two Tag Switching Routers (TSRs) over a connection
oriented transport layer with guaranteed sequential delivery (e.g.,
TCP). In other words, one TDP session is established between peer
TSRs. A TDP session is kept by sending keep-alive packets periodically
to its peer. If a TDP does not see keep-alive packets from its peer
within certain interval, the TDP session is deleted.

In ATM environment, a tag information exchanged (via TDP) between peer
TSRs contains a VPI/VCI of cell header [4], which puts a restriction
on Tag Switching that a TSR is not allowed to connect its peer via
conventional ATM switches since VPI/VCI is re-written at each ATM
switch.

When ATM-TSR receives a tag binding request for a certain route from
an upstream neighbor ATM-TSR, it creates the binding between incoming
tag (VPI/VCI) and the route, and advertises them to the peer that
originated the request. The ATM-TSR then requests for an outgoing tag
(VPI/VCI) to the next hop for that route. After receiving the binding
from the next hop neighbor, the ATM-TSR associates the incoming tag
with the outgoing tag, which enables cut-through packet forwarding.

Once a binding is created, it is not deleted as long as the route for
the corresponding destination is kept unchanged or the TDP session is
alive.

If a new binding request for a route arrives and there are already
some binding(s) for the same route, the ATM-TSR must create a new
different incoming tag for the same route and request for a different
outgoing tag. This is because packets which have the same destination
but arrived at different input interfaces cannot be multiplexed onto a
single VC unless some non-interleaving scheduling mechanism is
supported in the underlying L2 switch. As a result, the bindings are
created for each (ingress-TSR, destination address prefix).

When a tag binding is no longer needed, the ATM-TSR may delete the
binding and notify the next hop. Then the next hop ATM-TSR also
destroy the corresponding binding and notify the next hop, and this
process is repeated at each ATM-TSR. In this point, we can say that
globally synchronized (end-to-end) states are maintained by using TDP.

Tag Switching also allows a packet to carry a set of tags, organized
as a stack [1,5]. Each tag in a stack corresponds to each routing
hierarchy, e.g., BGP and IGP. This enables Tag Switching to scale.

2. Cell Switch Router (CSR)

In CSR [8], FANP (Flow Attribute Notification Protocol) [6] plays the
same role as TDP in Tag Switching.  FANP runs between two CSRs over
unreliable transport (the current FANP implementation runs over IP
with unreserved protocol-id). No FANP level session is established
between peer CSRs.

To identify the mapping between L3/L2 labels, a CSR allocates a VCID
(Virtual Connection IDentifier). FANP can support various types
(lengths) of VCIDs depending on L2. Fixed length (12-octet) VCID is
defined for ATM, which is composed of 6-octet ESI (End System
Identifier) of an ATM end-system address, and 6-octet ID which
uniquely identifies VCIDs allocated by the same CSR. The use of VCID
instead of VPI/VCI makes CSR independent of topological design. This
means that, with VCID negotiation procedure, CSRs can be
interconnected through the ATM switches that changes incoming VPI/VCI
values to the different outgoing VPI/VCI values.

VCIDs are uniquely allocated based mainly on a pair of IP source and
destination addresses. We refer to such a pair as a flow. The
allocation is made when the first trigger packet arrives. Trigger
packet is a packet which contains one of certain TCP/UDP port numbers
and certain address pair.  This type of allocation is called
"data-traffic-driven."

As for the VCID management over ATM, current FANP specification
supports upstream VCID allocation policy, e.g., after allocating a
VCID a CSR advertises the VCID and the corresponding (source,
destination) pair to the downstream neighbor CSR, and the receiving
CSR installs these information. Since the current CSR implementation
is flow-based, the receipt of incoming VCID does not trigger off a new
allocation of an outgoing VCID at the receiving CSR. Instead,
allocations are always triggered by arrivals of trigger packets.

After the mapping information for the flow is installed at the
downstream CSR, the CSR periodically sends refresh packets to the
upstream neighbor as long as there are any packet arrivals for that
flow in each period. Refresh packets are sent flow-by-flow. The
interval used to send refresh packets is called RefreshInterval. If no
data packet arrives within N*RefreshInterval, the mapping information
created for the incoming flow and the incoming VC for that flow are
deleted.

The upstream CSR sets a timer on receiving the first refresh packet
from its downstream neighbor.  The timer is called Dead Timer, and the
value set to Dead Timer is called DeadInterval. The upstream CSR keeps
the outgoing VC and the mapping information for that flow as long as
it receives a refresh packet from the downstream neighbor before Dead
Timer expires. Dead Timer is always reset on receiving a refresh
packet before expiration of Dead Timer. If no refresh packet is
received within DeadInterval, the CSR deletes the outgoing mapping
information and release the outgoing VC for that flow. This means that
CSR employs a soft state mechanism in mapping management. Note that
our implementation also allows state deletion at any time when a CSR
receives a release packet from its downstream neighbor.

Unlike Tag Switching, deletion of a state (mapping) for a flow is
executed locally, without notifying the deletion that would cause the
deletion of entire states for the flow along the path. Hence we can
say that local (link-by-link) states are maintained by using FANP.

























        Table 1: Comparison of Tag Switching and CSR
+-------------------+-------------------------+---------------------------+
|                   | Tag Switching           | CSR                       |
+===================+=========================+===========================+
| Method for        | (1) use existing        |                           |
| binding info.     |     protocol packets    | use FANP                  |
| delivery          | (2) use TDP             |                           |
+-------------------+-------------------------+---------------------------+
| Trigger to create | Route change            | Arrival of trigger packet |
| a state           |(control-traffic-driven) | (data-traffic-driven)     |
+-------------------+-------------------------+---------------------------+
| Unit of state     | (ingress-TSR,dst)       | (src,dst)                 |
+-------------------+-------------------------+---------------------------+
| Impact of         | Not local               | Local                     |
| state change      | (when TDP is used)      |                           |
+-------------------+-------------------------+---------------------------+
| Consistency with  | Both deletes old binding immediately                |
| routing state     | when routing state changes.                         |
+-------------------+-------------------------+---------------------------+
| Binding allocation| downstream allocation   | upstream allocation only  |
| policy            | (in most cases)         |                           |
+-------------------+-------------------------+---------------------------+
| How to deal with  | Loop prevention by using| Loop correction           |
| loops             | TDP hopcount or TTL     |                           |
|                   | field in tag stack      |                           |
+-------------------+-------------------------+---------------------------+
| Hierarchy support | Yes                     | No                        |
+-------------------+-------------------------+---------------------------+

3. Comparison

We summarize the features of Tag Switching and CSR in ATM environment
in Table 1.

3.1 Method for binding information delivery

There are two methods for Tag Switching to deliver binding
information: (1) using existing protocol packets, and (2) using TDP.
When method (1) is used, reliability of delivery is realized by the
carrying protocol. When method (2) is used, TCP guarantees the
reliability.  On the contrary, CSR always uses FANP for the binding
information delivery. FANP has its own reliable delivery mechanism,
used in common with unicast and multicast, over unreliable transport.

3.2 Trigger to create a state

Installation of state with the current CSR is driven by data traffic
for the legacy packet traffic. The operation overview for RSVP traffic
is given in [7]. In contrast installation of state with tag switching
is driven directly by control traffic (e.g., unicast routing updates,
RSVP messages, PIM messages).

3.3 Unit of state

In CSR, a state is created for (src, dst).  In Tag Switching, a state
is created for (ingress TSR, dst).

3.4 Impact of state change

When a state change occurs in a TSR with TDP, it causes direct state
changes at other TSRs (e.g., by sending TDP_PIE_REMOVE_BIND messages).
So, if a TDP session fails in some node, say A, for some reason, the
entire bindings for all routes that go through node A are completely
deleted from the network and only hop-by-hop packet transfer is
permitted for those routes, unless VC merging is not available. On the
contrary, changes in state with CSR are purely local, default-VC
(hop-by-hop) transfer is carried out only between node A and its
neighbor routers.

3.5 Consistency with routing state

When a routing state changes, both Tag Switching and CSR immediately
deletes the old bindings associated to the change, and creates new
bindings according to the new routing state.

3.6 Binding allocation policy

As for binding allocation, Tag Switching employs downstream allocation
policy in most cases whereas CSR employs upstream allocation
policy. However, downstream allocation seems inapplicable to multicast
cut-through on multi-access ATM network using the standard ATM
Forum/ITU-T signaling.

3.7 Loop detection

There are two methods to deal with loops over label switching path:
loop correction and loop prevention. In the loop correction, MPLS
level loops are allowed to be set up over a label switching path, and
data may be transmitted over the loops, but the loops is later
detected and closed. On the contrary, in the loop prevention, data is
never transmitted over a MPLS level loop.

CSR has a loop correction mechanism in which MPLS level loops
disappear as soon as the related L3 level loops disappear.
Tag Switching has two loop prevention mechanisms.
One method is using TDP level hop count which is carried in TDP
messages. Another method is using TTL field of tag
stack which is prepended to each IP packet [5].

3.8 Hierarchy support

The idea of hierarchical tag support in Tag Switching is good in terms
of scalability.

References

[1] Y. Rekhter et al.,
    "Cisco System's Tag Switching Architecture Overview,"
    Internet RFC 2105, Feb. 1997.

[2] F. Baker,
    "Use of Flow Label for Tag Switching," Internet Draft,
    draft-baker-flow-label-00.txt, Oct. 1996.

[3] P. Doolan et al.,
    "Tag Distribution Protocol," Internet Draft,
    draft-doolan-tdp-spec-00.txt, Sep. 1996.

[4] B. Davie et al.,
    "Use of Tag Switching With ATM," Internet Draft,
    draft-davie-tag-switching-atm-01.txt, Jan. 1997.

[5] E. Rosen et al.,
    "Tag Switching: Tag Stack Encodings," Internet Draft,
    draft-rosen-tag-stack-01.txt, March 1997.

[6] K. Nagami et al.,
    "Flow Attribute Notification Protocol (FANP) Specification,"
    Internet Draft, draft-rfced-info-nagami-00.txt, Nov. 1996.

[7] Y. Katsube et al.,
    "Interoperation Scenario Between Distinct Types of Cut-through,"
    Internet Draft, Apl. 1997.

[8] Y. Katsube et al.,
    "Toshiba's Router Architecture Extensions for ATM : Overview",
    Internet RFC 2098, Feb. 1997.







Authors

     Yoshihiro Ohba
    R&D Center, Toshiba Corporation,
    1 Komukai-Toshiba-cho, Saiwai-ku,
    Kawasaki, 210, Japan
    Tel: [phone]
    Fax: [phone]
    Email: [e-mail]

      Hiroshi Esaki
    Computer and Network Division,
    Toshiba Corporation,
    1-1-1 Shibaura,
    Minato-ku, 105-01, Japan.
    Tel: [phone]
    Fax: [phone]
    Email: [e-mail]

      Yasuhiro Katsube
    R&D Center, Toshiba Corporation,
    1 Komukai-Toshiba-cho, Saiwai-ku,
    Kawasaki, 210, Japan
    Tel: [phone]
    Fax: [phone]
    Email: [e-mail]

Acknowledgment

We appreciate Yakov Rekhter and Paul Doolan of Cisco Systems Inc.
for giving us comments on this document.