Internet Draft
Expiration Date: June 1998 Ken-ichi Nagami
Yasuhiro Katsube
Shigeo Matsuzawa
Akiyoshi Mogi
Koutarou Ise
Toshiba
Flow Attribute Notification Protocol Version 2 (FANPv2)
Distributed Control Mode
<draft-nagami-csr-fanpv2-dcmode-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-abstract.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 memo describes the specification of FANPv2 (Flow Attribute
Notification Protocol version 2) distributed control mode (DC-mode).
The FANPv2 is a protocol used by Cell Switch Routers (CSRs) to
communicate mapping information between a specific packet flow and a
virtual connection that conveys the packet flow. In the DC-mode,
the control message exchange for a packet flow between each pair of
neighboring CSRs is initiated independently from the message
exchange for the same flow between any other pair of CSRs. The
DC-mode is applicable to the control of both unicast and multicast
cut-through paths.
1. Introduction
The FANPv2 is a protocol used by Cell Switch Routers (CSRs)[1] to
Nagami, et al. [Page 1]
Internet Draft draft-nagami-csr-fanpv2-dcmode-00.txt December 1997
communicate mapping information between a specific packet flow and a
virtual connection that conveys the packet flow. This draft
describes the specification of FANPv2 distributed control mode
(DC-mode), which is one of the two modes provided by the FANPv2 as
described in [2].
In the DC-mode, the control message exchange for a packet flow
between each pair of neighboring CSRs is initiated independently
from the message exchanges for the same flow between any other pair
of CSRs. The DC-mode is applicable to the control of both unicast
and multicast cut-through paths.
The following descriptions assume ATM as a cut-through switching
technology although the protocol mechanism can be applied to the
other switching technologies such as frame-relay.
2. Terminology and Definitions
o VCID (Virtual Connection IDentifier) [8]
An identifier of a virtual connection (ATM VC or VP) that
is uniquely recognized by neighboring nodes.
In the case that the VPI/VCI values at both endpoints of the
VC are not the same, the VCID value is composed of the ESI
(End System Identifier) of either of the neighboring nodes
and the unique identifier within the node. In the case that
the VPI/VCI value at one endpoint of a VC is maintained at
another endpoint, the VPI/VCI value can be used as a VCID.
o Cut-through forwarding
Packet forwarding based on VPI/VCI values without layer 3
processing at the CSR.
Layer 3 information (e.g., destination IP address) is
associated with the corresponding VPI/VCI by using FANP.
o Hop-by-Hop forwarding
Packet forwarding based on layer 3 information like that of
conventional routers. In ATM, cells are re-assembled into
packets at the router, whose layer 3 headers are analyzed for
making a forwarding decision.
o Default-VC
A VC that is used for hop-by-hop forwarding. Cells received
from the Default-VC are reassembled into packets.
Conventional layer 3 processing is performed for these packets.
Control packets such as routing messages and FANP messages
are also transmitted over this VC.
o Dedicated-VC
Nagami, et al. [Page 2]
Internet Draft draft-nagami-csr-fanpv2-dcmode-00.txt December 1997
A VC that is used for a specific packet flow. When the
FlowID for an incoming VC and that for an outgoing VC are the
same at a CSR, it can forward the packets belonging to the
flow with the cut-through forwarding.
o Cut-through path
A sequence of dedicated-VCs which transmit packets belonging
to the same FlowID with the cut-through forwarding.
o FlowID (Flow IDentifier)
A set of parameters that identify a specific packet flow.
For example, an end-to-end layer 3 flow is identified by the
FlowID that contains a source IP address and a destination
IP address.
3. Cut-through Path Control Procedure
3.1 Overview of the Distributed Control Mode (DC-mode)
In the DC-mode, the cut-through path establishment procedure for a
packet flow is initiated at individual nodes on its path in a
distributed manner. Each of them transmits FANP control messages to
its downstream neighbor in order to notify the mapping relationship
between the packet flow and the outgoing dedicated-VC that will
convey the flow. The downstream node that has received the control
message from its upstream neighbor memorizes the received mapping
information at its incoming interface, and transmits an
acknowledgment to its upstream neighbor.
This message exchange with an upstream neighbor at the node does not
initiate the exchange of any control messages with its downstream
neighbor. A control message exchange for a flow between a pair of
CSRs is initiated and carried out independently from the message
exchange for the same flow between any other pair of nodes.
As a result of control message exchanges performed at individual
pairs of nodes, a node can perform cut-through packet forwarding
when it realizes that both the incoming dedicated-VC and the
outgoing dedicated-VC are associated with the same FlowID.
The cut-through path release procedure is also initiated at
individual nodes on the path. A node that has detected the trigger
to release the cut-through path transmits FANP control messages to
its downstream neighbor in order to cancel the mapping relationship
between the packet flow and the outgoing dedicated-VC that conveys
the flow. The reception of the control messages from the upstream
neighbor and the cancellation of the mapping relationship at an
incoming interface of a node do not become the trigger for the
Nagami, et al. [Page 3]
Internet Draft draft-nagami-csr-fanpv2-dcmode-00.txt December 1997
control message transmission toward its downstream neighbor.
Although concrete parameters for the cut-through establishment or
release trigger are not specified in this document, generic control
procedures in the case of two typical types of trigger
(traffic-driven and request-driven control) are described below.
This subsection describes cut-through path control procedure for the
case that neighboring nodes are interconnected by the point-to-point
link for simplicity. Procedures in the case that the neighboring
nodes are interconnected over other types of ATM datalink are
described in 3.2.
3.1.1 Traffic-driven Operation
3.1.1.1 Path Establishment / Release
Figure 1 shows a traffic-driven path establishment procedure for
unicast packet transmission from a sender H1 to a receiver H2.
Ingress edge router R1, CSR core router R2, and egress edge router
R3 are assumed to speak FANPv2 protocol.
Ingress edge router R1 transmits packets toward its downstream
neighbor R2 over a default-VC as a default behavior. When R1 decides
that a packet flow satisfies specific conditions for cut-through
path establishment, it initiates the path establishment
procedure. It selects a dedicated-VC for the packet flow, then
transmits a NOTIFY message, that notifies its downstream neighbor R2
of the mapping relationship between the packet flow and the selected
dedicated-VC, to R2. The identifier of the packet flow (FlowID) is
assumed to be source IP address H1 and destination IP address H2
(H1, H2). When R2 accepts the NOTIFY message sent by R1, it
transmits a NOTIFY ACK message to R1, which concludes a flow
notification step between R1 and R2.
Similarly, when R2 decides that the same packet flow as above
satisfies specific conditions for cut-through path establishment, it
selects a dedicated-VC that conveys the flow, then transmits a
NOTIFY message, that notifies its downstream neighbor R3 of the
mapping relationship between the flow and selected dedicated-VC, to
R3. When R3 accepts the NOTIFY message sent by R2, it transmits
NOTIFY ACK message to R2, which concludes a flow notification step
between R2 and R3. When R2 realizes that both the incoming
dedicated-VC from R1 and the outgoing dedicated-VC to R3 are
associated with the same flow, it can begin cut-through packet
transmission by concatenating the incoming and the outgoing
dedicated-VC at ATM level.
Nagami, et al. [Page 4]
Internet Draft draft-nagami-csr-fanpv2-dcmode-00.txt December 1997
Release of the cut-through paths is also performed by individual
nodes that have detected triggers to release the path. Each of them
transmits a REMOVE message, that notifies its downstream neighbor of
removal of the mapping relationship between the packet flow and the
dedicated-VC. The downstream node transmits a REMOVE ACK message to
the upstream node, which concludes a flow removal step between
neighboring nodes. Note that the removal of the mapping
relationship for a packet flow at an incoming interface of a node
does not initiate the flow removal step for the same flow at its
outgoing interface.
Examples of the trigger for cut-through path establishment and
release are shown below. One or several of them could be selected as
well as other triggers that are not itemized below. It is desirable
that the common triggers are adopted in a domain.
Establishment Trigger:
- Transmission of a packet with specific upper layer protocols
defined by the port-ID of TCP/UDP.
(ex. http, ftp, and nntp)
- Transmission of a 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.
Release Trigger:
- Decrease of the packet activity (no packet or less than a
certain amount of packets in a predetermined period).
- Change of a next-hop entry in a routing table related to
an active cut-through path.
- Recognition that a neighbor node isn't running through the
neighbor discovery protocol [4].
A similar procedure is applicable to a traffic-driven multicast
case. When establishing a multicast cut-through path, each node on
the multicast tree selects a dedicated-VC toward each of its
downstream neighbors, and then transmits a NOTIFY message, that
conveys a mapping relationship between the multicast packet flow and
the selected dedicated-VC, to each neighbors. The identifier of the
multicast packet flow (FlowID) would be source IP address and
multicast group address in the case that the source tree-based
multicast routing (e.g., DVMRP) is applied, while it would be IP
address of the core node and multicast group address in the case
that the core-based multicast routing (e.g., PIM-SM) is applied.
Trigger for cut-through establishment, e.g., transmission of
multicast packet, is detected by each node in a manner similar to
the unicast case. When a node has found a new multicast group member
Nagami, et al. [Page 5]
Internet Draft draft-nagami-csr-fanpv2-dcmode-00.txt December 1997
at one of its outgoing interfaces that was not the leaf of the tree,
it performs the same procedure as the initial establishment toward
the downstream neighbor at the interface. When a node, on the
contrary, has recognized that a multicast group member has left the
group at one of its outgoing interface, it performs the same
procedure as the release of the cut-through toward the downstream
neighbor at the interface.
3.1.1.2 Operation for Route Changes
When a node has recognized a change of the next-hop (downstream
neighbor) node for an active cut-through path, it stops cut-through
forwarding and transmits a REMOVE message to cancel the mapping
relationship for the related packet flow. The downstream node that
has received the REMOVE message sends back a REMOVE ACK message, but
does not perform the flow removal action toward its downstream
neighbor unless its own next-hop entry for the packet flow has been
changed. It will perform the flow removal action toward the
downstream neighbor if there is no packet activity from the upstream
neighbor.
The node that has completed the flow removal action toward the old
downstream neighbor performs the path establishment procedure toward
the new downstream neighbor by one of the establishment triggers
(e.g., transmission of a packet with specific upper layer
protocols).
+--+ Ethernet +--+ +-----+ +--+ +-----+ +--+ Ethernet +--+
|H1|----------|R1|---| ATM |---|R2|---| ATM |---|R3|----------|H2|
+--+ +--+ +-----+ +--+ +-----+ +--+ +--+
trigger pkt
|----------> trigger packet
|-------------> trigger packet
NOTIFY |--------------> trigger pkt
==============> NOTIFY |----------->
NOTIFY ACK ===============>
<============== NOTIFY ACK
<===============
|=============|
Dedicated-VC |==============|
Dedicated-VC
Figure 1.
3.1.2 Request-driven Operation
Nagami, et al. [Page 6]
Internet Draft draft-nagami-csr-fanpv2-dcmode-00.txt December 1997
3.1.2.1 Path Establishment/Release
Figure 2 shows a request-driven path establishment procedure for
packet transmission from a sender H1 to a receiver H2. The procedure
between neighboring nodes is the same as in the traffic-driven case.
The difference is that the trigger for the path establishment or
release is not related to the data packets but to the control
packets such as the RSVP messages[7].
In the case that the path establishment or release is triggered by
the RSVP messages, a cut-through path is established from downstream
to upstream along with the RSVP reservation (Resv) messages. R2
that has received a Resv message from R3 performs the flow
notification procedure by selecting a dedicated-VC for the requested
flow and transmitting a NOTIFY message to R3. R2 realizes that the
flow notification procedure has succeeded when it receives a
NOTIFY ACK message from R3, and then transmits a Resv message to its
upstream neighbor R1. R1 that has received Resv message from R2
performs the flow notification procedure between R2 similarly. R2,
as a result, realizes that both the incoming dedicated-VC from R1
and the outgoing dedicated-VC toward R3 are associated with the same
packet flow, and then is able to begin cut-through forwarding.
Release of the cut-through paths is also performed by individual
nodes that have recognized expiration of RSVP's reservation state.
Each of them transmits a REMOVE message, that notifies its
downstream neighbor of removal of the mapping relationship. The
expiration of the RSVP reservation state is detected by either
the reception of RSVP reservation tear message or the timeout of the
state refresh period.
Examples of the trigger for cut-through path establishment and
release in the request-driven case are shown below.
Establishment Trigger:
- Establishment of the RSVP reservation state.
Release Trigger:
- Expiration of the RSVP reservation state.
- Recognition that a neighbor node isn't running through the
neighbor discovery protocol.
Nagami, et al. [Page 7]
Internet Draft draft-nagami-csr-fanpv2-dcmode-00.txt December 1997
+--+ Ethernet +--+ +-----+ +--+ +-----+ +--+ Ethernet +--+
|H1|----------|R1|---| ATM |---|R2|---| ATM |---|R3|----------|H2|
+--+ +--+ +-----+ +--+ +-----+ +--+ +--+
Resv
<----------|
Resv
Resv <--------------|
Resv <-------------| NOTIFY
<----------| NOTIFY ===============>
==============> NOTIFY ACK
NOTIFY ACK <===============
<=============|
|==============|
|=============| Dedicated-VC
Dedicated-VC
Figure 2.
3.1.2.2 Operation for Route Changes
In the operation driven by RSVP, unlike the case of the
traffic-driven operation, a change of the next-hop node for the
packet flow with cut-through forwarding does not initiate the
procedure for changing the route of the cut-through path. Since the
RSVP process itself has a functionality to determine the reservation
path, e.g., route pinning, it is desirable that the route of the
RSVP flow is controlled by the RSVP process rather than the native
routing process.
3.2 Procedure Dependent on Datalink Type
A previous subsection described the cut-through path control
procedure for the case that neighboring FANP-capable nodes are
interconnected by the point-to-point link for simplicity. In
addition to the point-to-point link, it should be possible for the
nodes to be interconnected over various types of datalink such as
ATM networks that provide SVC services.
This subsection describes FANP procedures between neighboring nodes
which are interconnected over various types of ATM network as well
as by the point-to-point link.
3.2.1 Operational Overview
The FANP procedure between neighboring nodes is composed of :
(1)Dedicated-VC setup, (2)VCID notification, and (3)Flow
Nagami, et al. [Page 8]
Internet Draft draft-nagami-csr-fanpv2-dcmode-00.txt December 1997
notification for cut-through establishment, and (4)Flow removal,
(5)VCID removal, and (6)Dedicated-VC release for cut-through
teardown.
(1) Dedicated-VC setup :
It is performed only when the neighboring nodes are
interconnected over an ATM SVC network. An upstream node
establishes a dedicated-VC, by using ATM signaling procedure, so
as to be used as a cut-through path.
(2) VCID notification :
It is performed in the case that the VPI/VCI value of the cell
transmitted by the upstream node and that of the cell received
by the downstream node are not the same. Association between a
dedicated-VC and "VCID", which is being commonly recognized by
the neighboring nodes terminating the VC, is established at this
step. One of the following two types of procedure is performed
depending on the types of ATM network: i)use of an inband
message (PROPOSE message) that is transmitted over the
dedicated-VC being used, ii)use of a message (NOTIFY message)
that associates an Information Element (IE) conveyed by an ATM
signaling with a VCID value.
(3) Flow notification :
It is the core procedure that lets the neighboring nodes share
the common knowledge about mapping relationship between a packet
flow (FlowID) and a VCID. An upstream node notifies a
downstream node of the mapping relationship (NOTIFY message),
which is acknowledged by the downstream node (NOTIFY ACK
message). VCID notification and flow notification can be merged
into a single message when the two actions are performed
consecutively (see 3.2.5.1).
(4) Flow removal :
It is performed to cancel the registered mapping relationship
between a packet flow and a VCID. An upstream node transmits a
REMOVE_FLOW or REMOVE_ALL message to a downstream node, which is
acknowledged by the downstream node. The latter message is used
to perform the flow removal and the VCID removal (described
below) at once.
(5) VCID removal :
It is performed to cancel the association between the
dedicated-VC and the VCID allocated at the VCID notification
step.
(6) Dedicated-VC release :
It is performed only when the neighboring nodes are
interconnected over an ATM SVC network. An upstream node
Nagami, et al. [Page 9]
Internet Draft draft-nagami-csr-fanpv2-dcmode-00.txt December 1997
releases a dedicated-VC, by using ATM signaling procedure.
The following four types of datalink which interconnect neighboring
FANP-capable nodes are possible:
(a) Point-to-point link that interconnects neighboring nodes directly
(b) PVC-based ATM network
(c) VP-based ATM network that provides logical point-to-point link
(d) SVC-based ATM network
Some of the above-mentioned procedural steps (e.g., dedicated-VC
setup and VCID notification) could be omitted in the case of certain
datalink types, while all of the steps should be executed in the
case of other datalink types. Detailed procedures for individual
datalinks are described from 3.2.2 to 3.2.5.
Note that the FANP procedure will not work until each node
recognizes its neighbor nodes as FANP-capable through the neighbor
discovery protocol specified in [4]. Any messages received from an
unrecognized neighbor node must be discarded.
All the messages described in this section have a Sender ID and a
Receiver ID field except for a PROPOSE message. Each node should
fill in each of these fields with a Local ID and a Peer ID in its
neighbor table[4], respectively. If a Sender ID or a Receiver ID in
the received message is different from the Peer ID or the Local ID
in the neighbor table, the message must be discarded. All the FANP
messages except for a PROPOSE message are conveyed over a
default-VC.
3.2.2 Operation over Point-to-point Link
In the operation over the point-to-point link, neither the
dedicated-VC setup nor the dedicated-VC release is necessary since
there is no conventional ATM switch between neighboring
nodes. Neither the VCID notification nor the VCID removal is
necessary since the VPI/VCI value of an outgoing cell at an upstream
node and that of an incoming cell at a downstream node are the same
in this case.
When an upstream node has detected cut-through establishment trigger
for a packet flow, it determines VPI/VCI value of an available
dedicated-VC, and then transmits a NOTIFY[VCID, FlowID] message,
that conveys the VPI/VCI value as a VCID and the FlowID of the
packet flow, to its downstream neighbor node. The downstream node
sends back either an NOTIFY ACK or an ERROR message to the upstream
node.
Nagami, et al. [Page 10]
Internet Draft draft-nagami-csr-fanpv2-dcmode-00.txt December 1997
The upstream node periodically retransmits the NOTIFY[VCID, FlowID]
message when it has received neither a NOTIFY ACK nor an ERROR
message in a certain period of time. When it has not received any
response after a number of retransmissions, it proceeds to a flow
removal procedure described below. Default value of the
retransmission interval and the number of retransmissions are
described in Appendix C.
When an upstream node has detected cut-through release trigger for a
cut-through packet flow, it transmits a REMOVE_FLOW message, that
includes a VCID value, to the downstream node. The downstream node
sends back a REMOVE_FLOW ACK message to the upstream node. The
upstream node periodically retransmits the REMOVE_FLOW message when
it has not received REMOVE_FLOW ACK message in a certain period of
time. Default value of the retransmission interval is described in
Appendix C.
3.2.3 Operation over ATM PVC
In the operation over ATM PVC network, a certain amount of PVCs is
provided between neighboring nodes as an initialization procedure.
One of the unused PVCs is picked up as a dedicated-VC when a node
detects cut-through establishment trigger. As the VPI/VCI value of
an outgoing cell at an upstream node and that of an incoming cell at
a downstream node are not the same in general, it is necessary that
the dedicated-VC is given a VCID which can be uniquely identified by
both endpoints of the VC (VCID notification).
An upstream side of the PVC transmits a PROPOSE message to a
downstream side over the selected PVC itself, which conveys the VCID
value being allocated to the PVC. The downstream node sends back a
PROPOSE ACK message to the upstream node over a default-VC, which
concludes the VCID notification step.
The upstream node periodically retransmits the PROPOSE message when
it has received neither a PROPOSE ACK nor a PROPOSE NACK message in
a certain period of time. When it has not received any response
after a number of retransmissions, it proceeds to a VCID removal
procedure described below. Default value of the retransmission
interval and the number of retransmissions are described in Appendix
C.
After the VCID notification procedure has been successfully
completed, the flow notification and removal can be performed with
the same procedure as the point-to-point link case described in
3.2.2. The VCID notification procedure can be performed immediately
after the setup of the PVCs at the initialization phase, or when the
cut-through establishment trigger is detected.
Nagami, et al. [Page 11]
Internet Draft draft-nagami-csr-fanpv2-dcmode-00.txt December 1997
The VCID value allocated to the PVC at the VCID notification step
can be released by the VCID removal procedure. The upstream node
transmits a REMOVE_ALL message to the downstream node, which is
acknowledged by the downstream node with a REMOVE_ALL ACK message.
The upstream node periodically retransmits the REMOVE_ALL message
when it has not received REMOVE_ALL ACK message in a certain period
of time. Default value of the retransmission interval is described
in Appendix C.
3.2.4 Operation over ATM VP
In the operation over ATM VP network, one or several ATM VPs are
provided between neighboring nodes as an initialization procedure.
One of the unused VCIs is picked up as a dedicated-VC when a node
detects cut-through establishment trigger.
When a single VP is provided between neighboring nodes, all the
procedures are the same as in the case of the point-to-point link
operation described in 3.2.2 since the VCI value of an outgoing cell
at an upstream node and that of an incoming cell at a downstream
node are the same. When multiple VPs are provided between
neighboring nodes, on the other hand, the VCID notification step is
necessary in order that both nodes recognize which VPI as well as
VCI is going to be used as a dedicated-VC.
3.2.5 Operation over ATM SVC
In the operation over ATM SVC network, dedicated-VCs as well as
default-VCs are provided through the ATM signaling. Procedures for
cut-through establishment and release differ depending on,
(i)whether the BLLI(Broadband Low Layer Information) IE is available
in the underlying ATM signaling, and (ii)whether the SVC for a
dedicated-VC is set up each time the cut-through establishment
trigger is detected or a number of surplus SVCs are prepared (VC
pool[9]), one of which is picked up when the cut-through
establishment trigger is detected.
3.2.5.1 On-demand SVC Setup with BLLI IE
When an upstream node detects the cut-through establishment trigger,
it selects an available temporal ID value called LLID (Low Layer ID)
and an available VCID value, both of which are identifiers of a
dedicated-VC to be set up, and then sets up a dedicated-VC by ATM
signaling. The upstream node conveys the selected 7-bit LLID value
in the "user specified layer 3 protocol information field" of the
Nagami, et al. [Page 12]
Internet Draft draft-nagami-csr-fanpv2-dcmode-00.txt December 1997
BLLI IE of a SETUP message. When the SVC setup has been completed,
both the upstream and the downstream node memorize the LLID value as
an identifier of the SVC.
Then the upstream node transmits a NOTIFY[LLID, VCID, FlowID]
message to the downstream node, which functions as a VCID
notification and flow notification at the same time. At the time
that the NOTIFY[LLID, VCID, FlowID] message is acknowledged by the
downstream node, both nodes share the common knowledge about the
identifier "VCID" of the dedicated-VC and about the association
between the VCID and the "FlowID" that is the identifier of the
packet flow transmitted over the dedicated-VC. The LLID value can be
released at both nodes at this stage, and can be recycled for other
SVCs that are being set up.
When the upstream node detects the cut-through release trigger, it
transmits a REMOVE_ALL message to the downstream node, which
functions as a flow removal and VCID removal at the same time. Then
the SVC is released by the ATM signaling.
3.2.5.2 On-demand SVC Setup without BLLI IE
When the upstream node detects the cut-through establishment
trigger, it selects an available VCID value as an identifier of a
dedicated-VC to be set up, and then sets up a dedicated-VC by ATM
signaling. The temporal ID of the SVC, that is commonly recognized
by both nodes, is not able to be conveyed by the ATM signaling
message in this case.
When the SVC setup has been completed, the upstream node proceeds to
a VCID notification step and a flow notification step that are the
same as in the case of PVC described in 3.2.3.
The flow removal, VCID removal, and dedicated-VC release procedure
are the same as 3.2.5.1.
3.2.5.3 Operation with VC Pool
In the case that a number of surplus unused SVCs are prepared as a
pool, neighboring nodes do not have to perform the dedicated-VC
setup/release procedure nor the VCID notification/removal procedure
each time a specific cut-through establishment/release trigger is
detected. When the upstream node detects the trigger to prepare an
additional dedicated-VC as a pool, it initiates a dedicated-VC setup
procedure and a VCID notification procedure.
When the BLLI IE is supported by the ATM signaling, a temporal
Nagami, et al. [Page 13]
Internet Draft draft-nagami-csr-fanpv2-dcmode-00.txt December 1997
identifier of the SVC is selected by the upstream node and is
conveyed by the SVC SETUP message as described in 3.2.5.1. Then the
upstream node transmits a NOTIFY[LLID, VCID] message to the
downstream node, which functions as a VCID notification. At the time
that the NOTIFY[LLID, VCID] message is acknowledged by the
downstream node, both nodes recognize that the new SVC, which is
identified by the VCID, is registered into a "VC pool" for future
use as a dedicated-VC.
When the BLLI IE is not supported by the ATM signaling, the upstream
node sets up an SVC without conveying its temporal identifier, and
then proceeds to a VCID notification step that uses an inband
PROPOSE message as described in 3.2.3. At the time that the PROPOSE
message is acknowledged by the downstream node, both nodes
recognize that the new SVC, which is identified by the VCID, is
registered into a "VC pool" for future use as a dedicated-VC.
One of the available SVCs in a VC pool is picked up as a
dedicated-VC when a cut-through path is being set up. The flow
notification and the flow removal procedures are the same as the
procedure for the point-to-point link described in 3.2.2. When the
association with a specific flow is canceled by the flow removal
procedure, the SVC is returned to a VC pool for future use.
4. Message Format
FANP control messages are encapsulated in IP packets except for VCID
notification messages. The protocol ID for these messages is
110(decimal). They are transfered through default-VC. They consist
of a common header and object fields.
VCID notification messages(PROPOSE, PROPOSE ACK, PROPOSE NACK) are
carried in the extended ATM-ARP messages defined in RFC1577[6]. A
PROPOSE message is transferred from the upstream node to the
downstream node through the dedicated-VC. PROPOSE ACK and PROPOSE
NACK messages are transferred from the downstream node to the
upstream node through the default-VC.
The reserved field in the following packet format MUST be zero.
4.1 VCID Notification Message
PROPOSE, PROPOSE ACK and PROPOSE NACK messages are used for VCID
notification procedure. They use the extended ATM-ARP message
format [6] to which the VCID type and the VCID field are added.
Type & Length fields are set to zero, because the messages don't
need sender/target ATM address.
Nagami, et al. [Page 14]
Internet Draft draft-nagami-csr-fanpv2-dcmode-00.txt December 1997
PROPOSE message is transferred from the upstream node to the
downstream node through the dedicated-VC. PROPOSE ACK and PROPOSE
NACK messages are transferred from the downstream node to the
upstream node through the default-VC.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Hardware Type = 0x13 | Protocol Type = 0x0800 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type&Length 1 | Type&Length 2 | Operation Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length 1 | Type&Length 3 | Type&Length 4 | Length 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sender IP Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Target IP Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| VCID Type |VCID Length | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| VCID |
/ /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type&Length 1 ; Type & Length of sender ATM number = 0
Type&Length 2 ; Type & Length of sender ATM subnumber = 0
Type&Length 3 ; Type & Length of sender ATM number = 0
Type&Length 4 ; Type & Length of sender ATM subnumber = 0
Length 1 ; Source IP address length
Length 2 ; Target IP address length
Operation code
0x10 = PROPOSE
0x11 = PROPOSE ACK
0x12 = PROPOSE NACK
VCID Type: VCID Type field as described later
VCID Length: Length of VCID field (Byte)
VCID : VCID field as described later
4.2 FANP Common Header
FANP control messages except for VCID notification messages(PROPOSE,
PROPOSE ACK,PROPOSE NACK) consist of a FANP common header and FANP
objects described in section 4.3 .
Nagami, et al. [Page 15]
Internet Draft draft-nagami-csr-fanpv2-dcmode-00.txt December 1997
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version |I| Op Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sender ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Receiver ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ /
/ Object /
/ /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Version : The protocol version of FANP. This protocol version is 2.
I Flag :
This flag is zero if this message is for the DC-Mode.
This flag is one if this message is for the IC-Mode[3].
This flag is zero in HELLO,INIT,RECOGNIZE and KEEP_ALIVE messages.
Operation Code:
This field indicates the operation code of the message.
The value of operation code is as follows.
operation code = 1 : HELLO message
operation code = 2 : INIT message
operation code = 3 : RECOGNIZE message
operation code = 4 : KEEP_ALIVE message
operation code = 5 : ERROR message
operation code = 6 : NOTIFY message
operation code = 7 : NOTIFY ACK message
operation code = 8 : REMOVE_FLOW message
operation code = 9 : REMOVE_FLOW ACK message
operation code = 10 : REMOVE_ALL message
operation code = 11 : REMOVE_ALL ACK message
operation code = 12 : UPDATE message
(used by IC-mode)
operation code = 13 : UPDATE ACK message
(used by IC-mode)
Checksum
This field is the 16 bits checksum for the whole body of the
FANP message. The checksum algorithm is the same as that used
for the IP header.
Sender ID
The Local ID of the sender of the message. This field is zero
for HELLO messages.
Nagami, et al. [Page 16]
Internet Draft draft-nagami-csr-fanpv2-dcmode-00.txt December 1997
Receiver ID
The Local ID of the receiver of the message. This field is zero
for HELLO and INIT messages.
4.3 FANP Objects
4.3.1 Object Header
The FANP object header format is as follows.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Object Type | Object Flags | Object Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Object Type : The type of this object.
Object Flags : The flag of this object. The semantics of this field
depends on the object types.
Object Length : The length of the object (in bytes) includes the
object header.
4.3.2 Map Object
A format of MAP OBJECT, which maps VCID, FlowID and LLID, is as
follows. This object type is 1.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Object Type = 1| Reserved | Object Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| VCID Type | FlowID Type | Error Code | LLID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| VCID |
/ /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FlowID |
/ /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Object Type : Set to 1 for Map Object
Object Length : The length of the object (in bytes) includes the
object header.
Nagami, et al. [Page 17]
Internet Draft draft-nagami-csr-fanpv2-dcmode-00.txt December 1997
VCID Type : The type of VCID. It is zero if no VCID field.
FlowID Type : The type of FlowID. It is zero if no FlowID field.
Error Code : If this message is ERROR message, the following
error code is put into this field.
Error Code = 1: unknown VCID Type
Error Code = 2: unknown VCID
Error Code = 3: unknown FlowID Type
Error Code = 4: unknown FlowID
Error Code = 5: resource unavailable
Error Code = 6: refuse as a matter of policy
Error Code = 7: hop count threshold exceeded
(used by IC-mode)
Error Code = 8: same FlowID received on different interface
(used by IC-mode)
Error Code = 9: unknown LLID
LLID : The Low Layer ID (LLID) field. If LLID isn't needed,
this field is zero.
VCID : The VCID field as described latter.
FlowID : The FlowID field as described latter.
4.3.2.1 VCID Field Format
VCID type value decides VCID field format. Currently, only type "1"
and "2" are defined. The VCID field format 1 is shown below.
VCID Type = 1:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ESI of upstream node |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
ESI : IEEE 802 MAC address (ESI:End System Identifier [10])
of the upstream node.
ID : A unique identifier allocated by the upstream node.
Nagami, et al. [Page 18]
Internet Draft draft-nagami-csr-fanpv2-dcmode-00.txt December 1997
VCID Type = 2: Explicit ATM Label (4 bytes)
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Reservd| VPI | VCI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
4.3.2.2 FlowID field
FlowID type value decides FlowID field format. Currently, FlowID
type "1", "2" and "3" are defined. The format is shown below.
FlowID Type = 1:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source IP address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination IP address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Source IP address : source IP address of a flow
Destination IP address : destination IP address of a flow
FlowID Type = 2:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Protocol |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source IP address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination IP address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Protocol ID : protocol ID of a flow
Source IP address : source IP address of a flow
Destination IP address : destination IP address of a flow
Source port : source port of a flow. If a flow doesn't
have it, this field is zero.
Destination port : destination port of a flow. If a flow
doesn't have it, this field is zero.
Nagami, et al. [Page 19]
Internet Draft draft-nagami-csr-fanpv2-dcmode-00.txt December 1997
FlowID Type = 3:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination IP address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination network mask |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Destination IP address : destination IP address of a flow
Destination network mask : netmask of a flow
4.3.3 Capability Object
This object is only used by FANPv2-ND. The value of this object type
is 2. Details are described in [4].
4.3.4 VCID Range Object
This object is only used by FANPv2-ND. The value of this object type
is 3. Details are described in [4].
4.3.5 Hop Count Object
This object is only used by IC-Mode. The value of this object type
is 4. Details are described in [3].
4.3.6 Ingress Object
This object is only used by IC-Mode. The value of this object type
is 4. Details are described in [3].
4.4 Examples of Message
ERROR,NOTIFY,NOTIFY_ACK,REMOVE_FLOW,REMOVE_FLOW ACK,REMOVE_ALL and
REMOVE_ALL ACK messages have a common header and one or more than
one map objects.
<Common Header> <Map Object> [<Map Object> ....]
5. Security Considerations
Nagami, et al. [Page 20]
Internet Draft draft-nagami-csr-fanpv2-dcmode-00.txt December 1997
Security issues are not discussed in this document.
6. 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.
7. References
[1] Y. Katsube, et al., "Toshiba's Router Architecture Extensions for
ATM : Overview", RFC2098, Feb. 1997
[2] Y. Katsube, et al., "Cell Switch Router - Architecture and
Protocol Overview -", Internet Draft
draft-katusbe-csr-arch-00.txt(work in progress), Dec. 1997
[3] Y. Ohba, et al., "FANP Version 2 - Ingress Control Mode",
Internet Draft draft-ohba-csr-fanpv2-icmode-00.txt(work in
progress), Dec. 1997
[4] K. Nagami, et al., "FANP Version 2 - Neighbor Discovery",
Internet Draft draft-nagami-csr-fanpv2-nd-00.txt(work in
progress), Dec. 1997
[5] J. Heinanen, "Multiprotocol Encapsulation over ATM Adaptation
Layer 5", RFC1483, July 1993.
[6] M. Laubach, "Classical IP and ARP over ATM", RFC1577, Oct. 1993
[7] R. Braden, et al., "Resource ReSerVation Protocol (RSVP)",
RFC2205, Sep. 1997
[8] N. Demizu, et al., "VCID: Virtual Connection Identifier",
Internet Draft draft-demizu-mpls-vcid-01.txt, Oct. 1997
[9] N. Demizu, et al., "VC Pool", Internet Draft
draft-demizu-mpls-vcpool-00.txt, Oct. 1997
[10] "UNI Specification Version 3.1", ATM Forum, Sep. 1994
8. Authors' Addresses
Nagami, et al. [Page 21]
Internet Draft draft-nagami-csr-fanpv2-dcmode-00.txt December 1997
Ken-ichi Nagami
Research and Development Center, Toshiba
1, Komukai Toshiba-cho, Saiwai-ku, Kawasaki 210
Japan
Phone : +81-44-549-2238
EMail : nagami@isl.rdc.toshiba.co.jp
Yasuhiro Katsube
Research and Development Center, Toshiba
1, Komukai Toshiba-cho, Saiwai-ku, Kawasaki 210
Japan
Phone : +81-44-549-2238
EMail : katsube@isl.rdc.toshiba.co.jp
Shigeo Matsuzawa
Research and Development Center, Toshiba
1, Komukai Toshiba-cho, Saiwai-ku, Kawasaki 210
Japan
Phone : +81-44-549-2238
EMail : shigeom@isl.rdc.toshiba.co.jp
Akiyoshi Mogi
Research and Development Center, Toshiba
1, Komukai Toshiba-cho, Saiwai-ku, Kawasaki 210
Japan
Phone : +81-44-549-2238
EMail : mogi@isl.rdc.toshiba.co.jp
Koutarou Ise
Research and Development Center, Toshiba
1, Komukai Toshiba-cho, Saiwai-ku, Kawasaki 210
Japan
Phone : +81-44-549-2238
EMail : ise@isl.rdc.toshiba.co.jp
Appendix A: How to construct a default-VC
A default-VC in the case of ATM is as follows.
SVC : created using RFC1577[6]
PVC : set up by manual configuration
VP : VCI = 32 is reserved for the default-VC
Point-to-Point : VPI = 0, VCI = 32 is reserved for the default-VC
Appendix B: Packet Encapsulation
Nagami, et al. [Page 22]
Internet Draft draft-nagami-csr-fanpv2-dcmode-00.txt December 1997
In the case of ATM, the encapsulation over default-VCs and
dedicated-VCs is LLC encapsulation for routed non-ISO protocols
defined by RFC1483 [5].
Appendix C: Default Timer value / Default resend times
Timer:
HELLO Timer : 60 sec
Resend Timer(INIT,RECOGNIZE,KEEP ALIVE) : 30 sec
Resend Timer(others): 2,4,8,16,32,64,64,64,.... sec
Resend Times:
Resend PROPOSE : 3 times
Resend NOTIFY : 3 times
Nagami, et al. [Page 23]