One document matched: draft-katsube-csr-arch-00.txt
Internet-Draft
Yasuhiro Katsube
Ken-ichi Nagami
Yoshihiro Ohba
Shigeo Matsuzawa
Hiroshi Esaki
(Toshiba Corporation)
December 1997
Cell Switch Router
- Architecture and Protocol Overview -
<draft-katsube-csr-arch-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
This memorandum describes an internetworking architecture of Cell
Switch Router (CSR) and related control protocol overview. Cell
Switch Router is an ATM-based label switching router that can
provide ATM cut-through paths for packet flows with various levels
of granularity while retaining current router-based internetworking
architecture. The proposed architecture is able to provide the
cut-through path in response to the creation of IP forwarding entry
(topology-driven), the arrival of data packets (traffic-driven),
and the reception of control packets such as RSVP (request-driven).
One important feature that is provided by the proposed architecture
is interoperability with the emerging ATM network platform,
specified by the ATM Forum and/or ITU-T, which provides PVC
(Permanent Virtual Channel), VP (Virtual Path), or SVC (Switched
Virtual Channel) services.
Katsube, et al. Expires June 1998 [Page 1]
Internet Draft CSR - Architecture and Protocol - December 1997
Table of Contents
1. Introduction ................................................. 2
2. Internetworking Architecture Based on Cell Switch Router ..... 3
2.1 Architectural Overview ...................................... 3
2.2 Triggers for Cut-Through Path Establishment ................. 5
2.3 Interoperation with Standard ATM Network Platform ........... 6
3. Cell Switch Router Control Mechanism ......................... 8
3.1 Neighbor Discovery .......................................... 8
3.2 Two Modes of Protocol Operation ............................. 8
3.2.1 Distributed Control Mode (DC-mode) ........................ 8
3.2.1.1 Operational Overview .................................... 8
3.2.1.2 Examples of DC-mode Operation ........................... 9
3.2.2 Ingress Control Mode (IC-mode) ............................10
3.2.2.1 Operational Overview ....................................10
3.2.2.2 Examples of IC-mode Operation ...........................12
3.3 Operations Dependent on the Type of Underlying ATM Networks..12
3.3.1 PVC-based ATM network .....................................13
3.3.2 SVC-based ATM network .....................................13
4. Security Considerations ......................................14
5. Intellectual Property Rights Considerations ..................14
6. References ...................................................15
7. Authors' Addresses ...........................................15
1. Introduction
The Internet is growing in both size and traffic volume. In
addition, emerging applications may require specific bandwidth and
quality of services (QoSs) in addition to best effort. Such changes
require conventional routers with more sophisticated processing
capability, which tends to raise the cost of routers, and accelerate
investigations of a new internetworking architecture that relies on
powerful datalink switching capabilities.
The proposed internetworking architecture is composed of i)CSRs
that have ATM label switching capability as well as conventional
layer 3 packet forwarding, ii)edge nodes that are located at
boundaries between the proposed network and legacy networks (e.g.,
ATM networks with legacy routers, non-ATM networks), and iii)end hosts
that are capable of speaking with the CSRs.
Direct ATM level connectivities from ingress edge nodes (or hosts)
to egress edge nodes (or hosts) are provided via intermediate CSRs
on the path with the ATM label switching capability inside (we refer
to this ATM level connectivity as an "ATM cut-through path"). The
cut-through path is controlled by each of the CSRs on the path as
Katsube, et al. Expires June 1998 [Page 2]
Internet Draft CSR - Architecture and Protocol - December 1997
well as by ingress/egress edge routers or hosts, which keeps
conventional hop-by-hop control discipline for managing dynamic
layer 3 state for unicast and multicast routing, RSVP, and so on.
The proposed internetworking architecture is designed so as to be
able to operate over standard ATM networks which are compliant with
ATM Forum and/or ITU-T that support PVC (Permanent Virtual Channel),
VP (Virtual Path), or SVC (Switched Virtual Channel) services, as
well as over point-to- point links.
2. Internetworking Architecture Based on Cell Switch Router
2.1 Architectural Overview
Cell Switch Router(CSR) is a key network element of the proposed
internetworking architecture[13]. It is interconnected with ATM
networks through ATM UNI interface[1] and provides cell switching
functionality in addition to conventional IP packet forwarding. It
is able to concatenate incoming and outgoing ATM VCs at the ATM
layer, bypassing packet header processing. By carrying out such ATM
VC concatenations at multiple CSRs consecutively, ATM level
cut-through paths composed of multiple VCs, each of which connects
neighboring CSRs (or CSR and hosts/edge routers), can be provided.
Two different kinds of VCs for transmitting packets are defined
between neighboring CSRs or between CSR and hosts/edge routers.
1) Default-VC : a general-purpose VC used by any communications that
select conventional hop-by-hop IP forwarding paths. All incoming
cells received from this VC are assembled into IP packets and
handled based on their IP headers.
2) Dedicated-VC : used by a specific packet flow, which is specified
by, e.g., {dst.IP address, src.IP address} or {dst.IP address,
src.IP address, protocol, dst.port, src.port}. It can be
concatenated with other Dedicated-VC(s) that accommodate the same
packet flow as itself, and can constitute an ATM cut-through path
for those packet flows.
The route for a cut-through path follows IP routing information in
each CSR. As shown in Figure 1, packets from an ingress edge router
(or source host) X.1 to an egress edge router (or destination host)
Z.1 are transferred over the route X.1 --> CSR1 --> CSR2 --> Z.1
regardless of whether the communication is on a hop-by-hop IP
forwarding basis or cut-through path basis.
An example of the IP packet transmission mechanism is as follows.
- The ingress edge X.1 checks an identifier of each IP packet flow,
Katsube, et al. Expires June 1998 [Page 3]
Internet Draft CSR - Architecture and Protocol - December 1997
which may be the "destination IP address (or prefix)",
"source/destination IP address (prefix) pair", "source/destination
IP address and port" or "source IP address and group address".
Based on such identifiers, it determines over which VC the packet
should be transmitted.
- The CSR1 and CSR2 check the VPI/VCI value of each incoming cell.
When the mapping from the incoming interface/VPI/VCI to outgoing
interface/VPI/VCI (which may be plural in the case of multicast) is
found in an ATM forwarding table, it is directly forwarded to the
specified interface(s) with the new VPI/VCI value through an ATM
switch module. When the mapping is not found in the ATM forwarding
table (or the table shows an IP processing module as an output
interface), the cell is transmitted to an IP processing module and
assembled into an IP packet and then forwarded to an appropriate
outgoing interface/VPI/VCI based on the header of the packet.
IP subnet X IP subnet Y IP subnet Z
<---------------------> <-----------------> <--------------------->
+-------+ Default +-------+ Default +-------+ Default +-------+
| | -VC | CSR 1 | -VC | CSR 2 | -VC | |
| Host +=============+ +===============+ +=============+ Host |
| or +-------------+++++---------------+++++-------------+ or |
| Edge +-------------+++++---------------+++++-------------+ Edge |
| X.1 +-------------+++++---------------+++++-------------+ Z.1 |
| |Dedicated | | Dedicated | |Dedicated | |
+-------+ -VCs +-------+ -VCs +-------+ -VCs +-------+
<--------------------------------------------------->
Cut-through Path
Figure 1 Internetworking Architecture based on CSR
A CSR becomes the termination point (egress edge) of a cut-through
path when it is an edge of the ATM cloud regarding the end-to-end
path, it is an edge of the CSR-capable router cloud regarding the
end-to-end path, or it cannot create a Dedicated-VC toward the
downstream neighbor for the end-to-end path for some reason. The
CSR-capable router is required to understand a control protocol that
exchanges mapping information between each dedicated-VC and a
specific packet flow that will be transmitted over the VC.
Note that the egress edge of the cut-through path can also perform
the cut-through forwarding which bypasses IP processing. Since the
Katsube, et al. Expires June 1998 [Page 4]
Internet Draft CSR - Architecture and Protocol - December 1997
egress edge router can memorize the association between each of the
cut-through paths it terminates and the specific packet flow which
is transmitted over the path by using the control protocol described
in section 3, it can obtain the same information as by referring to
the IP header, i.e., source IP address and destination IP address
etc., by referring to the identifier of the incoming dedicated-VC
(VPI/VCI). That means that the egress edge router can forward
packets received from the dedicated-VC to a proper downstream
neighbor without referring to their IP header even though the
corresponding outgoing dedicated-VC does not exist.
In the rest of the document, all the CSR-capable devices including
CSR, edge router, and end host will be referred to as "CSR" for
simplicity unless there is a need to distinguish among them.
2.2 Triggers for Cut-Through Path Establishment
CSR is able to initiate cut-through path establishment in response
to the creation of IP forwarding table entries (topology-driven),
the arrival of data packets (traffic-driven), and the reception of
control traffic such as RSVP resource reservation request (request-
driven)[2].
This subsection describes three triggers for cut-through path
establishment by CSRs, together with possible granularity of packet
flows (conditions that specify the packet flow conveyed over the
cut-through path) in each of the cases.
1) Topology-driven path establishment :
In topology-driven, the cut-through path establishment procedure is
initiated when a new IP level forwarding table entry is created at a
CSR. The cut-through path can naturally accommodate aggregated
packet flow which is specified by, e.g., {ingress edge router,
dest.prefix}, {ingress edge router, egress edge router}, {*,
dest.prefix}, or {*, egress edge router}. The latter two may require
ATM switches to provide flow merging capability while avoiding AAL5
frame interleaving.
Note that the topology-driven aggregated paths should not be
extended beyond the points where the processing for individual
end-end flows (e.g., packet filtering or QoS differentiation) should
be carried out but be terminated at those points.
2) Traffic-driven path establishment :
Katsube, et al. Expires June 1998 [Page 5]
Internet Draft CSR - Architecture and Protocol - December 1997
In traffic-driven, the path setup procedure is initiated when the
CSR determines that it is worth providing the path for a specific
packet flow, e.g.,
* transmission of a packet with specific upper layer protocols
defined by the port ID of TCP/UDP
* transmission of TCP SYN packet
* transmission of a packet with specific source/destination IP
addresses
* transmission of more than a certain amount of packets in a
predetermined period
Granularity of the packet flow for the traffic-driven path could be
{src.IP_addr, dest.IP_addr} as a default, although aggregated
cut-through paths specified by, e.g., {ingress edge router,
dest.prefix}, can also be established with traffic-driven.
3) Request-driven path establishment :
In request-driven, the path setup procedure is initiated when the
CSR receives some control messages (requests) which are not specific
to CSR network but affect the cut-through operation of the CSR. An
example of such a control message is RSVP Reservation (Resv) request
[3] which requests the CSR to provide specific quality of services
with regard to the packet forwarding. The CSR which has received a
Resv message prepares a dedicated-VC for the requested RSVP flow.
Granularity of the packet flow for the request(RSVP)-driven path
could be {src.IP_addr/port, dest.IP_addr/port} as a default although
{src.IP_addr, dest.IP_addr} may be allowable in some
cases. Reservation styles shared by multiple senders (Wild Card
style and Shared Explicit style) should be supported by the
cut-through paths dedicated to individual senders like a Fixed
Filter style for simplicity.
2.3 Interoperation with Standard ATM Network Platform
Interconnecting multiple CSRs through point-to-point (p-p) links
such as SONET link is a straightforward configuration that is easy
to implement. In addition, CSRs are designed to be interconnected
with each other over the emerging ATM network platform that is
compliant with the ATM Forum or ITU-T standard UNI. That enables the
ATM network platform to be utilized for Internet/Intranet services
as well as other services such as telephony and native ATM services.
In addition, Internet/Intranet services based on CSRs can coexist
with and operate over classical IP over ATM[4] networks, which
provide intra-subnet communications.
Katsube, et al. Expires June 1998 [Page 6]
Internet Draft CSR - Architecture and Protocol - December 1997
CSR operations over three types of ATM networks should be taken into
account;
1) VP-based ATM network : provides a VP as a tunnel between
neighboring CSRs and picks up an unused VCI in the VP each time
a dedicated-VC is needed.
2) PVC-based ATM network : provides a number of PVCs between
neighboring CSRs at an initialization phase and picks up one of
them each time a dedicated-VC is needed.
3) SVC-based ATM network : provides an SVC between neighboring CSRs
through ATM signaling each time a dedicated-VC is needed.
In the case 3), it is possible that a number of SVCs are set up in
advance through ATM signaling and are registered as a stock, which
we call "VC pool" approach[5]. Then one of them can be picked up
each time a dedicated-VC is needed, which is a similar approach to
the PVC case. Although the necessary VC resources with the VC pool
approach will be larger than the on-demand SVC setup, the VC pool
approach can decrease latency for setting up the cut-through path as
there is no delay for ATM signaling. In addition, the VC pool
approach can reduce the processing burden for setting up or
releasing SVCs when the number of surplus VCs between neighboring
CSRs is controlled between a predetermined lower bound and an upper
bound. That is, an additional SVC is set up only when the number of
surplus SVCs becomes smaller than a predetermined lower bound,
whereas one of the surplus SVCs is released only when it becomes
larger than a predetermined upper bound. Whether the "on-demand
setup approach" or "VC pool approach" should be applied is a matter
of local decision in each network, taking cost and the system
responsiveness into account.
ATM networks can be utilized either as logical point-to-point links
in which IP addresses are assigned to a CSR for each neighbor CSR,
or as a multi-access (NBMA) link in which a single IP address is
assigned to a CSR for each logical IP subnet (LIS) composed of
several neighbor CSRs. When CSRs are operated over multi-access ATM
LIS environment, point-to-point (p-p) dedicated-VCs or
point-to-multipoint (p-mp) dedicated-VCs toward its next-hop(s) are
utilized by each CSR to provide intra-subnet connectivity. ATMARP
server[4] or MARS [6] will be used when the CSR does not know an ATM
address(es) of its neighbor CSR(s) or edge node(s). Note that this
does not exclude the use of other methods for unicast/multicast ATM
address resolution.
Katsube, et al. Expires June 1998 [Page 7]
Internet Draft CSR - Architecture and Protocol - December 1997
3. Cell Switch Router Control Mechanism
This section presents an overview of "FANP (Flow Attribute
Notification Protocol)", that is a protocol between neighboring
nodes (CSRs, edge routers, and end hosts) in order to establish,
maintain, and tear down the cut-through paths.
There are several changes in an updated version of FANP (FANP
version 2) from FANP v1[7]. They are i)provision of a neighbor
discovery protocol[8] that enables CSRs to recognize their
neighbors, ii)adoption of two modes of cut-through path control
mechanism; Distributed Control mode (DC-mode)[9] and Ingress Control
mode (IC-mode)[10], and iii)support of interoperability with variety
of ATM network platforms. Each of them will be explained in this
section.
3.1 Neighbor Discovery
The neighbor discovery (ND) is used for recognizing neighbors that
understand FANPv2, obtaining FANPv2 protocol attributes of the
neighbors, and checking whether consistent states are maintained by
the neighboring CSRs. A FANP-capable node recognizes that FANP is
running on a neighbor node provided it periodically receives ND
messages from the neighbor.
The ND procedure takes different actions depending on whether the
underlying network interface is point-to-point or multi-access.
Detailed procedure for each type of interface is described in [8].
3.2 Two Modes of Protocol Operation
CSR supports two modes of control operation; Distributed Control
mode (DC-mode)[9] and Ingress Control mode (IC-mode)[10]. An
overview and examples of application of each operation mode are
described below. Which mode of operation each control message
belongs to is distinguished by a bit in the common header of the
FANP message.
3.2.1 Distributed Control Mode (DC-mode)
3.2.1.1 Operational overview
In the DC-mode, the cut-through path establishment procedure for a
packet flow is initiated at individual CSRs on its path in a
distributed manner. Each of them transmits control messages to its
downstream neighbor in order to notify the mapping relationship
between the packet flow and the outgoing dedicated-VC that will
Katsube, et al. Expires June 1998 [Page 8]
Internet Draft CSR - Architecture and Protocol - December 1997
convey the flow. The downstream CSR that has received the control
message from its upstream neighbor checks the validity of the
message, memorizes the received mapping information at its incoming
interface, and transmits an acknowledgment to the upstream neighbor.
This message exchange with an upstream neighbor at the CSR does not
initiate the exchange of any control messages with its downstream
neighbor in the DC-mode. A control message exchange for a flow
between a pair of neighboring CSRs is initiated and carried out
independently from the message exchange for the same flow between
any other pair of CSRs. As a result of control message exchanges
performed at individual pair of CSRs, a CSR realizes that both the
incoming and the outgoing dedicated-VC are associated with the same
packet flow, and then begins cut-through forwarding.
The release of the cut-through path is also initiated at individual
CSRs on the path. A CSR that has detected the trigger to release the
cut-through path transmits control messages to its downstream
neighbor to cancel the association between the packet flow and the
outgoing dedicated-VC that conveys the flow. The reception of the
control message at a CSR from the upstream neighbor does not
initiate the transmission of the control message to the downstream
neighbor.
As no information regarding the cut-through path with edge-to-edge
importance can be obtained in the DC-mode, an ingress edge knows
neither the number of hops for the path nor the constitution of the
loop in the path. It is easy to change the configuration of
cut-through paths according to dynamic changes in the router state,
e.g., unicast routing, multicast group membership/routing, and RSVP
reservation state.
The common rule with regard to the trigger selection for the cut-
through path establishment (the condition to initiate the
cut-through establishment) and release, and the granularity level of
the packet flow should be configured to individual CSRs in a domain,
since no such information is conveyed hop-by-hop by the control
messages in the DC-mode.
3.2.1.2 Examples of DC-mode Operation
The DC-mode operation can be adopted for establishing the traffic-
driven unicast cut-through paths. Individual CSRs on the path can
recognize the flow of the layer 3 level end-to-end granularity by
referring to the data packets (e.g., {src.IP_addr., dest.IP_addr}).
They can also commonly recognize the aggregated flow of
{src.IP_addr., dest.prefix} granularity individually as long as
they have the IP forwarding table entry with the same CIDR prefix
Katsube, et al. Expires June 1998 [Page 9]
Internet Draft CSR - Architecture and Protocol - December 1997
given by the routing protocol.
Control of multicast cut-through paths is suitable for the DC-mode
operation as the management of group membership, which may change
frequently, is carried out by individual CSRs on the distribution
tree. Each CSR is able to add a new leaf to or delete a leaf from
the active cut-through path in response to detection of join or
leave of a group member at corresponding interfaces. The granularity
of {src.IP_addr., multicast group addr.} is straightforward although
the shared tree defined by, e.g., {Rendezveus Point, multicast group
addr.} is also possible. Concrete triggers for cut-through
establishment or release may depend on the routing protocol deployed
and implementation. Arrival of the data traffic, creation of the
multicast forwarding cache, or reception of PIM Join messages can be
the trigger.
Control of cut-through paths in response to the RSVP reservation
state (request-driven) at individual CSRs on the path will also be
appropriate for the DC-mode operation. Reception of the reservation
(Resv) messages at a CSR from its downstream neighbor initiates the
control message exchange, which notifies the mapping relationship
between the flow corresponding to the RSVP session and the
dedicated-VC that will convey the flow, with the downstream
neighbor. Then the CSR transmits the Resv message further upstream.
Here we assume the use of current standard RSVP message format[3]
with no additional object defined for this purpose.
3.2.2 Ingress Control Mode (IC-mode)
3.2.2.1 Operational overview
In the IC-mode, the cut-through path establishment procedure for a
packet flow is initiated by a CSR that is hoping to become an
ingress edge of the cut-through path. The ingress edge transmits
control messages to its downstream neighbor in order to notify the
mapping relationship between the packet flow and the Dedicated-VC
that will convey the flow. The message is composed of i)information
that identifies the flow, ii)information that identifies the
dedicated-VC, iii)ingress information that is uniquely created by
the ingress node for the cut-through path, and iv)a hop count that
is set to one by the ingress edge. The last two information elements
are specific to the IC-mode operation, which provides a capability
to prevent the creation of a potential loop of the cut-through path.
The CSR that has received the messages for the notification of the
mapping relationship from the upstream neighbor checks the validity
of the message, and memorizes the received mapping information at
its incoming interface. Then the CSR reconstructs and transmits
Katsube, et al. Expires June 1998 [Page 10]
Internet Draft CSR - Architecture and Protocol - December 1997
control messages further downstream along the path of the flow to
notify the mapping relationship between the flow notified by the
upstream neighbor and a dedicated-VC that will convey the flow.
The same procedure is performed at every CSR along the path of the
flow until the notification message reaches the CSR that cannot
extend the cut-through path any more (e.g., an egress edge of the
CSR cloud). The CSR that becomes the egress endpoint of the
cut-through path returns the acknowledgment message to its upstream
neighbor, which is forwarded hop-by-hop toward the ingress edge (the
ingress point of the cut-through path).
This ingress to egress and egress to ingress message forwarding
facilitates association of related information about the cut-through
path. As mentioned above, the control message that notifies the
mapping relationship contains "a hop count from the ingress edge"
and "an ingress information that is determined by the ingress edge
for the cut-through path it originates". The hop count value is
initially set to one by the ingress edge and is incremented by one
at each of the CSRs along the cut-through path. When a CSR
recognizes that the hop-count value in the notification message
reaches a predetermined threshold, it determines that there is a
potential loop in the cut-through path. The CSR also determines that
there is a potential loop when it has received a notification
message that contains the packet flow identifier and ingress
information, both of which are the same as those already registered,
but contains the dedicated-VC identifier that is not the same as has
been registered. The CSR that detects the potential loop stops
creation of the cut-through path toward its downstream, and returns
an error message to the upstream neighbor.
The ingress edge is able to know the number of hops from itself to
the egress endpoint of the cut-through path by referring to the
acknowledgement messages initiated by the egress node. The hop-count
in the acknowledgement message transmitted by the egress node is set
to one and incremented by one at each of the CSRs along the reverse
path of the cut-through. The ingress edge may decrement the TTL
value of the received packet by the number of hops it learned, or
may decrement that by one.
In the IC-mode, the CSR that has failed to extend the cut-through
path toward its downstream for specific reasons retries path
establishment after some specified intervals. When the CSR has
succeeded in extending the cut-through path by the retry procedure,
the number of hops from the CSR to the egress edge may change, which
means that the number of hops from the ingress edge to the egress
edge may also change. The CSR that has succeeded in extending the
cut-through path transmits a message that notifies an updated
hop-count from the egress edge toward the ingress edge.
Katsube, et al. Expires June 1998 [Page 11]
Internet Draft CSR - Architecture and Protocol - December 1997
3.2.2.2 Examples of IC-mode Operation
The IC-mode operation can be adopted for establishing the unicast
cut-through paths with aggregated packet flows as well as flows with
fine granularity level. Examples of the flow granularity are
{ingress edge's IP_addr., dest.prefix} and {ingress edge's IP_addr.,
egress edge's IP_addr.}. The trigger to establish the cut-through
path may be either topology-driven or traffic-driven. Irrespective
of the flow granularity and cut-through establishment trigger, the
notification message is processed at each CSR along the path and
transmitted hop-by-hop until it arrives at an egress edge.
3.3 Operations Dependent on the Type of Underlying ATM Networks
As described in 2.3, CSRs should be interconnected over the
following four types of datalink:
(a) Point-to-point link that interconnects neighboring CSRs directly
(b) VP-based ATM network that provides logical point-to-point link
(c) PVC-based ATM network
(d) SVC-based ATM network
The core procedure of the FANPv2 control mechanism performed by the
neighboring CSRs is a notification of the association between a
packet flow and a dedicated-VC that will convey the packet flow, and
an acknowledgment to the notification, which we call "flow
notification procedure". The use of the VPI/VCI value as an
identifier of a dedicated-VC in the flow notification procedure
would suffice in the case (a) and (b). It, however, does not work
when CSRs are interconnected over an ATM network that provides PVC
or SVC services. Since VPI/VCI values at the origination point
(outgoing interface of the upstream CSR) and the termination point
(incoming interface of the downstream CSR) of a VC are not the same
when there are standard ATM switches in between, the VPI/VCI value
cannot be used as an identifier of a dedicated-VC in the flow
notification procedure.
A "VCID (Virtual Connection IDentifier)"[11] is introduced instead,
which can be uniquely identified by the neighboring CSRs to indicate
a dedicated-VC in the flow notification procedure. In the case of
(c)PVC-based ATM network and (d)SVC-based ATM network, a procedure
to assign the VCID to each dedicated-VC, which we call "VCID
notification procedure", should be performed before the flow
notification procedure. Note that in the case of (a)the p-p link
and (b)the VP-based ATM network, no explicit VCID notification
procedure is needed since the VPI/VCI (or just the VCI) value in the
cell header can be used as the VCID in those cases.
Katsube, et al. Expires June 1998 [Page 12]
Internet Draft CSR - Architecture and Protocol - December 1997
The concrete procedure for the VCID notification differs depending
on the type of the underlying ATM network: PVC-based ATM or
SVC-based ATM[12].
3.3.1 PVC-based ATM network
An upstream CSR transmits a message that includes a VCID value over
the PVC itself (in-band notification). The VCID value is determined
by the upstream CSR and should be unique to the pair of CSRs. When
the downstream CSR transmits the acknowledgment of the above in-band
message to the upstream CSR, the upstream and downstream CSRs can
share the same identifier VCID for the PVC. This in-band VCID
notification procedure can be carried out either immediately after
the PVC setup or at the time when one of PVCs is picked up for a
specific cut-through path in response to cut-through establishment
trigger.
3.3.2 SVC-based ATM network
There are two ways for the VCID notification in the case of the SVC-
based ATM network. One is the in-band notification described above;
an upstream CSR conveys the VCID value over the SVC that is being
utilized as a dedicated-VC. This would be adopted when the other way
described below is not applicable.
An alternative way for the VCID notification is the use of an
Information Element (IE) with end-to-end significance in a SETUP
message of ATM signaling. When an upstream CSR transmits an ATM SVC
SETUP message toward its downstream neighbor, it determines a unique
ID value as the VCID and includes it in the IE that is transparently
conveyed by the ATM switches in between. After that, the upstream
CSR is able to perform the flow notification procedure by using the
above VCID as an identifier of the dedicated-VC. A "user specified
layer 3 protocol information field" of the BLLI (Broadband Low Layer
Information) IE is the most appropriate field for this purpose. An
issue in this method is that the user specified layer 3 protocol
information field of the BLLI IE is given just 7 bits, which can
identify only 128 VCs simultaneously between neighboring CSRs.
In order to resolve the limitation of the 7-bit BLLI IE, an
additional message exchange that notifies the mapping between the
7-bit number conveyed in the BLLI IE (a temporal VCID) and an actual
VCID, which is determined uniquely by the upstream CSR and is given
enough bit space, is carried out at the VCID notification phase.
Namely, after the upstream CSR has set up an SVC with the 7-bit
temporal ID value, it transmits a control message that replaces the
temporal ID with the VCID. At this stage, the temporal ID value is
released and could be reused by the other SVC. The flow notification
Katsube, et al. Expires June 1998 [Page 13]
Internet Draft CSR - Architecture and Protocol - December 1997
procedure will be performed by exchanging the message that conveys
the association between the VCID and a specific packet flow. The
procedure is:
1) SVC SETUP with temporal ID in the BLLI IE
2) VCID notification : message exchange that replaces "temporal
ID" with "VCID" (temporal ID is released for the other SVCs)
3) Flow notification : message exchange that notifies association
between the "VCID" and a specific "packet flow"
In the case that the "VC pool" approach described in 2.3 is applied,
the above steps 1) and 2) are carried out when preparing a
dedicated-VC for future use, and the step 3) is carried out when
establishing a cut-through path. In the case that the "on-demand
setup" approach described in 2.3 is applied, it is possible to
perform the above two steps 2) and 3) by a single message exchange.
By making the flow notification message convey the "temporal ID",
"VCID", and "packet flow", the VCID notification step can be merged
into the flow notification step. The procedure comes to:
1) SVC SETUP with temporal ID in the BLLI IE
2) Flow notification : message exchange that notifies association
between the "temporal ID", "VCID" and a specific "packet flow"
(temporal ID is released for the other SVCs)
The detailed procedure for the cut-through establishment and release
in individual cases is described in [9].
4. Security Considerations
Security issues are not discussed in this document.
5. Intellectual Property Considerations
Toshiba Corporation may seek patent or other intellectual property
protection for some or all of the aspects of the technology
discussed in this document. If any standards arising from this
document are or become protected by one or more patents assigned to
Toshiba Corporation, Toshiba intends to license them on reasonable
and non- discriminatory terms.
6. References
[1] The ATM Forum, "ATM User-Network Interface Specification, v3.1",
Katsube, et al. Expires June 1998 [Page 14]
Internet Draft CSR - Architecture and Protocol - December 1997
Sept. 1994.
[2] R. Callon, et al., "A Framework of Multiprotocol Label Switching",
IETF Internet-Draft (work in progress), draft-ietf-mpls-framework-
01.txt, July 1997.
[3] R. Braden, et al., "Resource ReSerVation Protocol (RSVP),
Version 1 Functional Specification", IETF RFC2205, Sept. 1997.
[4] M. Laubach, "Classical IP and ARP over ATM", IETF RFC1577,
Oct. 1993.
[5] N. Demizu, et al., "VC Pool", IETF Internet-Draft (work in
progress), draft-demizu-mpls-vcpool-00.txt, Oct. 1997.
[6] G. Armitage, "Support for Multicast over UNI 3.0/3.1 based
ATM Networks", IETF RFC2022, Nov. 1996
[7] K. Nagami, et al., "Toshiba's Flow Attribute Notification
Protocol (FANP) Specification", IETF RFC2129, April 1997.
[8] K. Nagami, et al., "Flow Attribute Notification Protocol
Version 2 (FANPv2) Neighbor Discovery", IETF Internet-Draft
(work in progress), draft-nagami-fanpv2-nd-00.txt, Dec. 1997
[9] K. Nagami, et al., "Flow Attribute Notification Protocol
Version 2 (FANPv2) Distributed Control Mode", IETF Internet-
Draft (work in progress), draft-nagami-csr-fanpv2-dcmode-00.txt,
Dec. 1997.
[10] Y. Ohba, et al., "Flow Attribute Notification Protocol Version 2
(FANPv2) Ingress Control Mode", IETF Internet-Draft (work in
progress), draft-ohba-csr-fanpv2-icmode-00.txt, Dec. 1997.
[11] N. Demizu, et al., "VC-ID: Virtual Connection Identifier", IETF
Internet-Draft (work in progress), draft-demizu-mpls-vcid-01.txt,
Oct. 1997.
[12] N. Demizu, et al., "ATM SVC Support for ATM-LSRs", IETF Internet-
Draft (work in progress), draft-demizu-mpls-atm-svc-00.txt,
Oct. 1997.
[13] Y. Katsube, et al., "Toshiba's Router Architecture Extensions
for ATM : Overview", IETF RFC2098, Feb. 1997.
7. Authors' Addresses
Yasuhiro Katsube
Research and Development Center, Toshiba Corporation
1, Komukai Toshiba-cho, Saiwai-ku, Kawasaki 210
Japan
Phone : +81-44-549-2238
E-mail : katsube@isl.rdc.toshiba.co.jp
Ken-ichi Nagami
Research and Development Center, Toshiba Corporation
1, Komukai Toshiba-cho, Saiwai-ku, Kawasaki 210
Japan
Phone : +81-44-549-2238
E-mail : nagami@isl.rdc.toshiba.co.jp
Katsube, et al. Expires June 1998 [Page 15]
Internet Draft CSR - Architecture and Protocol - December 1997
Yoshihiro Ohba
Research and Development Center, Toshiba Corporation
1, Komukai Toshiba-cho, Saiwai-ku, Kawasaki 210
Japan
Phone : +81-44-549-2238
E-mail : ohba@csl.rdc.toshiba.co.jp
Shigeo Matsuzawa
Research and Development Center, Toshiba Corporation
1, Komukai Toshiba-cho, Saiwai-ku, Kawasaki 210
Japan
Phone : +81-44-549-2238
E-mail : shigeom@isl.rdc.toshiba.co.jp
Hiroshi Esaki
Computer and Network Division, Toshiba Corporation
1-1-1 Shibaura, Minato-ku, 105-01,
Japan
Phone : +81-3-3457-2563
E-mail: hiroshi@isl.rdc.toshiba.co.jp
Katsube, et al. Expires June 1998 [Page 16]
| PAFTECH AB 2003-2026 | 2026-04-23 18:07:27 |