As per Relevance of the word upstream, we have this rfc below:
Network Working Group K.
Request for Comments: 2129 Y.
Category: Informational Y.
A.
S.
T.
H.
Toshiba R&D
April 1997
Toshiba's Flow Attribute Notification Protocol (FANP)
Status of this
This memo provides information for the Internet community. This
does not specify an Internet standard of any kind. Distribution
this memo is unlimited
This memo discusses Flow Attribute Notification Protocol (FANP),
which is a protocol between neighbor nodes for the management
cut-through packet forwarding functionalities. In cut-through
forwarding, a router doesn't have to perform conventional IP
processing for received packets. FANP indicates mapping
between a datalink connection and a packet flow to the neighbor
and helps a pair of nodes manage the mapping information. By
FANP, routers (e.g., CSR; Cell Switch Router) can forward
packets based on their datalink-level connection identifiers
bypassing usual IP packet processing. The design policy of the
is
(1) soft-state cut-through path (Dedicated-VC)
(2) protocol between neighbor nodes instead of end-to-
(3) applicable to any connection oriented datalink
1.
Due to the scalability requirement, connection oriented (CO)
platforms, e.g., ATM and Frame Relay, are going to be used as well
connection less (CL) datalink platforms, e.g., Ethernet and FDDI
One of the important features of the CO datalink is the presence of
datalink-level connection identifier. In the CO datalink, we
establish multiple virtual connections (VCs) with their
identifiers among the nodes. When we aggregate packets that have
same direction (e.g., having the same destination IP address) into
single VC, we can forward the packets in the VC without
Nagami, et. al. Informational [Page 1]
RFC 2129 FANP Specification April 1997
processing. With this configuration, routers can decide which
is the next-hop for the packets based on the VC identifier. CSRs [1]
can forward the incoming packets using an ATM switch engine
the conventional IP processing. According to the ingress VPI/
value with ingress interface information, CSR determines the
interface and egress VPI/VCI value
In order to configure the cut-through packet forwarding state, a
of neighbor nodes have to share the mapping information between
packet flow and the datalink VC. FANP (Flow Attribute
Protocol) described in this memo is the protocol to configure
manage the cut-through packet forwarding state
2. Protocol Requirements and Future
2.1 Protocol
The followings are the protocol requirements for FANP
(1) Applicable to various types of CO datalink
(2) Available with various connection types (i.e., SVC, PVC, VP
(3) Robust
The system should operate correctly even under the
conditions
(a) VC
Some systems can detect VC failure as the function
datalink (e.g., OAM function in the ATM). However, we
not assume all nodes in the system can detect VC failure
The system has to operate correctly, assuming that
node can not detect VC failure
(b) Message
Control messages in the FANP may be lost. The system has
operate correctly, even when some control messages are lost
(c Node
A node may be down without any explicit notification to
neighbors. The system has to operate correctly, even
node failure
Though FANP is not the protocol only for ATM, the
discussion assumes that the datalink is an ATM network
Nagami, et. al. Informational [Page 2]
RFC 2129 FANP Specification April 1997
2.2 Future
The followings are the future enhancements to be done
(1) Aggregated
In this memo, we define the flow which contain source
destination IP address. As this may require many
resources, we also need a new definition of aggregated
which includes several end-to-end flows. The
definition of the aggregated flow is for future study
(2) Providing multicast
(3) Supporting IP level QOS signaling like
(4) Supporting IPv
3. Terminology and
o VCID (Virtual Connection IDentifier
Since VPI/VCI values at the origination and the termination
of a VC (and VP) may not be the same, we need an identifier
uniquely identify the datalink connection between neighbor nodes
We define this identifier as a VCID. Currently, only one type
VCID is defined. This VCID contains the ESI (End
Identifier) of a source node and the unique identifier within
source node
o Flow ID (Flow IDentifier
IP level packet flow is identified by some parameters in a packet
Currently, only one type of flow ID is defined. This flow
contains a source IP address and a destination IP address.
that flow ID used in this specification is not the same as
flow-id specified in IPv6.
o Cut-through packet
Packets are forwarded without any IP processing at the
using the datalink level information (e.g.,VPI/VCI).
Internetworking level information (e.g., destination IP address
is mapped to the corresponding datalink-level identifier by
the FANP
o Hop-by-Hop packet
Packets are forwarded using IP level information like
routers. In ATM, cells are re-assembled into packets at
router to analyze the IP header
Nagami, et. al. Informational [Page 3]
RFC 2129 FANP Specification April 1997
o Default-
Default-VC is used for hop-by-hop packet forwarding.
received from the Default-VC are reassembled into IP packets
Conventional IP processing is performed for these packets.
encapsulation over the Default-VC is LLC for routed non-
protocols defined by RFC1483 [3].
o Dedicated-
Dedicated-VC is used for the specific IP packet flow identified
the flow-ID. When the flow-ID for an incoming VC and an
VC are the same at a CSR, it can forward the packets belonging
the flow through the cut-through packet forwarding.
encapsulation over the Dedicated-VC is LLC for routed non-
protocols defined by RFC1483 [3].
o Cut-through
When a FANP capable node receives a trigger packet, it tries
establish Dedicated-VC and to notify the mapping
between the Dedicated-VC and the IP packet flow which the
trigger packet belongs to. Trigger packets are defined by
port-ID of TCP/UDP with the local policy of each FANP
node. In general, they would be the port-ID's of sessions with
long life-time and/or with large amount of packets; e.g., http
ftp and nntp. Future implementation will include other
such as an arrival of resource reservation request
4. Protocol
Figure 1 shows an operational overview of FANP. In the figure,
cut-through packet forwarding path is established from host 1 (H1)
host 2 (H2) using two Dedicated-VCs. H1 and H2 are connected
Ethernets, and R1, R2 and R3 are routers which can speak FANP. R
and R3 have both an ATM interface and an Ethernet interface. R2
two ATM interfaces
When R1 receives an IP packet from H1, R1 analyzes the payload of
received IP packet whether it is a trigger packet or not. When
received packet is a trigger packet, R1 fetches a Dedicated-VC to
downstream neighbor(R2) and sends FANP messages. FANP is
between the neighboring nodes only. The same procedure would
performed between R2 and R3 independently from the procedure
R1 and R2. The flow-ID of the packet flow from H1 to H2
represented as id(H1,H2). Here, id(H1,H2) is the set of the
address of H1 and that of H2.
Nagami, et. al. Informational [Page 4]
RFC 2129 FANP Specification April 1997
The Dedicated-VC is released when no packet is transferred on it
a given period. We do not need to explicitly indicate release of
Dedicated-VC to the neighbor node, since the state management in
is of soft-state, rather than of hard-state
+--+ Ethernet +--+ +-----+ +--+ +-----+ +--+ Ethernet +--+
|H1|----------|R1|---| ATM |---|R2|---| ATM |---|R3|----------|H2|
+--+ +--+ +-----+ +--+ +-----+ +--+ +--+
trigger
|----------> trigger
|-------------> trigger
FANP |--------------> trigger
<=============> FANP |----------->
<==============>
|=============|
Dedicated-VC |==============|
Dedicated-
Figure 1. Trigger packet and FANP
5. Protocol
FANP has the following five procedures, that are (1) Dedicated-
selection, (2) VCID negotiation, (3) flow-ID notification, (4)
Dedicated-VC refresh and (5) Dedicated-VC release. Procedures (2),
(3) and (4) have nothing to do with the kind of the Dedicated
VC;i.e.,SVC,PVC or VP. On the contrary, the procedures (1) and (5)
with SVC are different from the procedures with PVC and with VP
The detailed procedures are described in the following subsections
5.1 Dedicated-VC Selection
A VC is picked up in order to use as a Dedicated-VC. The ways
picking up the Dedicated-VC is either of the followings
(1) A number of VCs are prepared in advance, and registered into
un-used VC list. When a Dedicated-VC is needed, one of them
picked up from the un-used VC list
(2) A new VC is established through ATM signaling on demand
With ATM PVC/VP configuration, a Dedicated-VC is activated by
procedure (1).
Nagami, et. al. Informational [Page 5]
RFC 2129 FANP Specification April 1997
With ATM SVC configuration, a Dedicated-VC is activated by
procedure (1) or (2). When the procedure (1) is used, some number
VCs are prepared in advance through ATM signaling. These VCs
registered into the un-used VC list. When a Dedicated-VC is needed
a VC is picked up from the un-used VC list. When the procedure (2)
is used, a Dedicated-VC is established through ATM signaling
time it is required
The procedure (1) can decrease a time to activate a Dedicated-VC
But the necessary VC resource will increase as it need to
additional VCs. Which procedure should be applied to is a matter
local decision in each node, taking the economical requirement
the system responsiveness into account
A Dedicated-VC is used as a uni-directional VC, although it
generally bi-directional. This means that packets are
only from upstream node to downstream node in the Dedicated-VC.
packets from downstream node to upstream node are transferred
the Default-VC or through another Dedicated-VC
5.2 VCID Negotiation
After the Dedicated-VC selection procedure, the upstream
transmits the PROPOSE message to the downstream node through
Dedicated-VC. The PROPOSE message contains a VCID for
Dedicated-VC and IP address (target IP address) of downstream node
When the downstream node accepts the PROPOSE message, it
the PROPOSE ACK message to the upstream node through the Default-VC
With this procedure, the upstream and the downstream nodes (
end-points of the Dedicated-VC) can share the same indicator "VCID
for the Dedicated-VC. When the downstream node can not accept
proposal from the upstream node with some reason (e.g., policy),
downstream node sends an ERROR message to the upstream node
the Default-VC
The procedure at the downstream node which has received
message is
1. if(Target IP address of the PROPOSE message isn't equal to my
address
then Goto end
2. if(The PROPOSE message should be refused
then Send an ERROR(refuse by policy) message. Go to end
3. if(VCID Type in the PROPOSE message isn't known
then Send an ERROR(unknown VCID Type) message. Go to end
Nagami, et. al. Informational [Page 6]
RFC 2129 FANP Specification April 1997
4. if(The VCID in the PROPOSE message is the same as the VCID
has already been registered for another Dedicated-VC in the node
then Delete the registered VCID
Release the old Dedicated-VC
5. if(A VCID is registered for the Dedicated-VC which has
the PROPOSE message
then Delete the registered VCID
6. Register the mapping between VCID and I/F, VPI, VCI for
Dedicated-VC
7. if(The mapping is successful
then Send a PROPOSE ACK
else Send an ERROR(resource unavailable).
The upstream node retransmits the PROPOSE message when it
receive PROPOSE ACK message nor ERROR message. When the
node has received neither of the messages even with
retransmissions of the PROPOSE message, the Dedicated-VC picked
through the Dedicated-VC selection procedure should be released
Here, the number of retransmissions (five in this specification)
recommended value and can be modified in the future
The purpose of the VCID negotiation procedure is not only to
the VCID information regarding the Dedicated-VC, but also to
whether the Dedicated-VC is available and whether the neighbor
operates correctly
If the VCID negotiation procedure with a neighbor node always fails
it is considered that the node may not be FANP-capable node
Therefore the upstream node should not try the VCID
procedure to that node for a certain time period
5.3 Flow-ID Notification
After the VCID negotiation procedure, the upstream node transmits
OFFER message to the downstream node through the Default-VC.
OFFER message contains the VCID of the Dedicated-VC, the flow-ID
the packet flow transferred through the Dedicated-VC and the
interval of a READY message
When the downstream node receives the OFFER message from the
node, it transmits the READY message to the upstream node through
Default-VC in order to indicate that the OFFER message issued by
upstream node is accepted. By the reception of the READY message
the upstream node realizes that the downstream node can receive
packets transferred through the Dedicated-VC
Nagami, et. al. Informational [Page 7]
RFC 2129 FANP Specification April 1997
The upstream node retransmits the OFFER message when it does
receive a READY message from the downstream node. When the
node has not receive a READY message even with five retransmissions
the Dedicated-VC should be released. Here, the number
retransmissions (i.e., five in this specification) is a
value and may be modified in the future
The node transmits an ERROR message to its neighbor in the
cases. When the node receives the ERROR message, the Dedicated-
should be released
(a) unknown VCID: The VCID in the message is unknown
(b) unknown VCID Type: The VCID Type is unknown
(c) unknown flow-ID Type: the flow-ID Type is unknown
When the downstream node accepts the OFFER message from the
node, it must send a READY message to the upstream node within
refresh interval offered by the upstream node. If it can not,
downstream node sends the ERROR message (this refresh interval is
supported) to the upstream node. The downstream node should
the refresh interval larger than 120 seconds. Therefore
downstream node shouldn't send the ERROR message (this
interval is not supported) when the refresh interval in the
message is larger than 120 seconds
The following describes the procedure of the node which has
an OFFER message
1. if(unknown version in the OFFER message
then Discard the message. Goto end
2. if(unknown VCID Type in the OFFER message
then Send an ERROR (unknown VCID Type) message. Goto end
3. if(VCID in the OFFER message has not been registered
then Send an ERROR (unknown VCID) message. Goto end
4. if(unknown Flow ID Type in the OFFER message
then Send an ERROR (unknown Flow ID Type) message. Goto end
5. if(refuse Flow ID in the OFFER message
then Send an ERROR (refused by policy) message. Goto end
6. if(refuse refresh interval in the OFFER message
then Send an ERROR(This refresh interval is not supported
message. Goto end
Nagami, et. al. Informational [Page 8]
RFC 2129 FANP Specification April 1997
7. if(the mapping between Flow ID and VCID already exists
Flow ID in the OFFER message is different from the
Flow ID for the corresponding VCID
then Do Flow-ID removal procedure. Goto end
8. Do the procedure of receiving the OFFER message
7. if(successful
then Send a READY message
else Send an ERROR (resource unavailable) message
8. end
The procedure of the node which has received a READY message
described
1. if(unknown version in the READY message
then Discard the message. Goto end
2. if(unknown VCID Type in the READY message
then Send an ERROR (unknown VCID Type) message. Goto end
3. if(VCID in the READY message has not been registered
then Send an ERROR (unknown VCID) message. Goto end
4. if(unknown Flow ID Type in the READY message
then Send an ERROR (unknown Flow ID Type) message. Goto end
5. if((the mapping between Flow ID and VCID doesn't exist)||
(the mapping between Flow ID and VCID already exists
Flow ID in the READY message is different from registered
ID for the corresponding VCID))
then Send an ERROR (unknown VCID) message. Goto end
6. Do the procedure of receiving the READY message
7. end
5.4 Flow ID Refresh
While the downstream node receives IP packets through the Dedicated
VC, it should periodically (with a refresh interval) send the
message to the upstream node. When the downstream node does
receive any IP packet during the refresh interval, it does not
the READY message to the upstream node
Nagami, et. al. Informational [Page 9]
RFC 2129 FANP Specification April 1997
While the upstream node continues to receive READY messages,
realizes that it can transmit the IP packets through the Dedicated
VC. When it does not receive a READY message at all for
predetermined period (dead interval), it removes the mapping
the Flow IP and VCID. The dead interval is defined below
When the upstream node falls into failure without the Flow ID
procedure for a Dedicated-VC, its mapping must be removed by
downstream node. The downstream node removes the mapping between
Flow ID and VCID for the Dedicated-VC when it does not receive any
packet for a "removal period" (=refresh interval times m).
The refresh interval, the dead interval and the removal period
satisfy the following equation
refresh interval < dead interval < removal period (=
interval times m
The recommended values are
refresh interval = 2
dead interval = 6 minutes (=refresh interval x 3)
removal period = 20 minutes (=refresh interval x 10)
5.5 Flow ID Removal
When the upstream node realizes that the Dedicated-VC is not used,
performs a Flow ID removal procedure
The Flow ID removal procedure differs between the case of PVC/
configuration and the case of SVC configuration
With the PVC/VP configuration, the upstream node issues a
message to the downstream node, and the downstream node sends back
REMOVE ACK message to the upstream node. The upstream
retransmits REMOVE messages when it does not receive a REMOVE
message. The upstream node assumes that the downstream node is
failure state when it dose not receive any REMOVE ACK message
the downstream node even with five REMOVE message retransmissions
Nagami, et. al. Informational [Page 10]
RFC 2129 FANP Specification April 1997
With SVC configuration, two procedures are possible. One is that
mapping between the Flow ID and the VCID is removed without
release of the ATM connection, which is the same procedure as
PVC/VP configuration. The other procedure is that the
between the Flow ID and the VCID is removed by releasing the
through ATM signaling. The former procedure can promptly create
delete the mapping between Flow ID and VCID, since the ATM
does not have to be performed each time. However, an un-used
connections have to be maintained by the node. Which procedure
applied to is a matter of each CSR's local decision, taking the
resource cost and responsiveness into account
The downstream node may want to remove the mapping between the
ID and the VCID. When the upstream node receives the REMOVE message
it sends a REMOVE ACK message to the downstream node
+--+ +--+
|R1|------------------------------|R2|
+--+ +--+
| PROPOSE |
|===============================>|
VCID | [VCID, target IP] |
negotiation | PROPOSE ACK |
|<===============================|
| [VCID] |
| |
| OFFER |
|===============================>|
Flow-ID | [VCID, flow-ID] |
notification | READY |
|<===============================|
| [VCID, flow-ID] |
| |
: : :
: : :
| READY |
|<===============================|
Dedicated-VC | [VCID, flow-ID] |
refresh | READY |
|<===============================|
| [VCID, flow-ID] |
Figure 2. Flow ID notification and refresh
Nagami, et. al. Informational [Page 11]
RFC 2129 FANP Specification April 1997
+--+ +--+
|R1|------------------------------|R2|
+--+ +--+
| |
| REMOVE |
|================================>|
| [VCID] |
| |
| REMOVE ACK |
|<================================|
| [VCID] |
(a) Flow ID removal (independent of ATM signaling
+--+ +--+
|R1|------------------------------|R2|
+--+ +--+
| ATM signaling |
| (release) |
|<===============================>|
| |
(b) Flow ID removal through ATM
Figure 3. Flow ID removal
6. Message
FANP control procedure includes seven messages described from 6.2
6.8. Among them, a PROPOSE message used for VCID
procedure uses an extended ATM ARP message format defined in RFC1577
[2]. The other messages are encapsulated into IP packets
The destination IP address in the IP packet header signifies
neighbor node's IP address and the source IP address
sender's IP address. Currently, the protocol ID for these
is 110(decimal). This protocol ID must be registered by IANA
The reserved field in the following packet format must be zero
Nagami, et. al. Informational [Page 12]
RFC 2129 FANP Specification April 1997
6.1 Field
6.1.1 VCID
VCID type value decides VCID field format. Currently, only type "1"
is defined. The VCID field format of VCID type 1 is shown below
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 field: ESI of upstream
ID : upstream node decides unique identifier
6.1.2 Flow ID
Flow ID type value decides flow-ID field format. Currently, flow-
type "0" and "1" are defined. The flow ID type value "0"
that the flow ID field is null. When flow ID type value is "1",
format shown below is used
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
Destination IP address : destination IP address of
6.2 PROPOSE
PROPOSE message uses the extended ATM-ARP message format [2] to
the VCID type and the VCID field are added. Type & Length fields
set to zero, because the messages don't need sender/target
address. This message is transferred from the upstream node to
downstream node through the Dedicated-VC
PROPOSE message is transferred from the upstream node to
downstream node through the Dedicated-VC
Nagami, et. al. Informational [Page 13]
RFC 2129 FANP Specification April 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Hardware Type = 0x13 | Protocol Type = 0x0800 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type&Length 1 | Type&Length 2 | Opereation 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 2 ; Target IP address
Operation
0x10 =
VCID Type: Currently , VCID Type = 1 is defined
VCID Length: Length of VCID
VCID : VCID described
6.3 PROPOSE
PROPOSE ACK messages is transferred 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version |Op code = 1 | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| VCID type |Flow-ID type=0 | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| VCID |
/ /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Nagami, et. al. Informational [Page 14]
RFC 2129 FANP Specification April 1997
This field indicates the version number of FANP. Currently
Version = 1
Operation
This field indicates the operation code of the message.
are five operation codes, below
operation code = 1 : PROPOSE ACK
This field is the 16 bits checksum for whole body of FANP message
The checksum algorithm is same as the IP header
VCID
This field indicates the VCID type. Currently, only "1"
defined
6.4 OFFER
OFFER message is transferred from an upstream node to a
node. The following is the message format
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 = 1 | Op Code = 2 | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| VCID type |Flow-ID type | Refresh Interval |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| VCID |
/ /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flow-ID |
/ /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Refresh
This field indicates the interval of refresh timer. The
interval is represented by second in integer. This field
used only in OFFER message. Recommended value is 120 (second).
Nagami, et. al. Informational [Page 15]
RFC 2129 FANP Specification April 1997
6.5 READY
READY message is transfered from a downstream node to an
node. This message is transferred when the downstream node
OFFER message. And this message is transferred periodically in
refresh interval. The following is the message format
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 = 1 | Op Code = 3 | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| VCID type |Flow-ID type | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| VCID |
/ /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flow-ID |
/ /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
6.6 ERROR
ERROR message is transfered from a downstream node to an
node or from an upstream node to a downstream node. This message
transferred when some of the fields in the receive message is
or refused. When the receive message is the ERROR message,
message isn't sent. VCID type ,VCID, Flow ID Type and Flow ID
in the ERROR message are filled with the same field in the
message
The following is the message format
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 = 1 | Op Code = 4 | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| VCID type |Flow-ID type | Error code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| VCID |
/ /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flow-ID |
/ /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Nagami, et. al. Informational [Page 16]
RFC 2129 FANP Specification April 1997
Error Code = 1 : unknown VCID
= 2 : unknown Flow-ID
= 3 : unknown
= 4 : resource is
= 5 : unavailable refresh interval is
= 6 : refuse by
6.7 REMOVE
REMOVE message is transfered from a downstream node to an
node or vice versa. This message is transferred to remove
mapping relationship between the flow ID and and the VCID. The
which receives REMOVE message must send REMOVE ACK message, even
VCID in the receive message isn't known .
The following is the message format
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 = 1 | Op Code = 5 | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| VCID type |Flow-ID type | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| VCID |
/ /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
6.8 REMOVE ACK
REMOVE ACK message is transferred from a downstream node to
upstream node or from an upstream node to a downstream node.
following is the message format
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 = 1 | Op Code = 6 | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| VCID type |Flow-ID type | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| VCID |
/ /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Nagami, et. al. Informational [Page 17]
RFC 2129 FANP Specification April 1997
7. Security
Security issues are not discussed in this memo
8.
[1] Katsube, Y., Nagami, K., and H. Esaki, "Router
Extensions for ATM; overview", Work in Progress
[2] Laubach, M., "Classical IP and ARP over ATM", RFC 1577,
October 1993.
[3] Heinanen, J., "Multiprotocol Encapsulation over ATM
Layer 5", RFC 1483, July 1993.
Ethernet is a registered trademark of Xerox Corp. All other
names mentioned herein may be trademarks of their
companies
9. Authors'
Ken-ichi
R&D Center,
1 Komukai Toshiba-cho, Saiwai-ku, Kawasaki 210
Phone : +81-44-549-2238
EMail : nagami@isl.rdc.toshiba.co.
Yasuhiro
R&D Center,
1 Komukai Toshiba-cho, Saiwai-ku, Kawasaki 210
Phone : +81-44-549-2238
EMail : katsube@isl.rdc.toshiba.co.
Yasuro
R&D Center,
1 Komukai Toshiba-cho, Saiwai-ku, Kawasaki 210
Phone : +81-44-549-2238
Email : masahata@csl.rdc.toshiba.co.
Akiyoshi
R&D Center,
1 Komukai Toshiba-cho, Saiwai-ku, Kawasaki 210
Phone : +81-44-549-2238
EMail : mogi@isl.rdc.toshiba.co.
Nagami, et. al. Informational [Page 18]
RFC 2129 FANP Specification April 1997
Shigeo
R&D Center,
1 Komukai Toshiba-cho, Saiwai-ku, Kawasaki 210
Phone : +81-44-549-2238
EMail : shigeom@isl.rdc.toshiba.co.
Tatsuya
R&D Center,
1 Komukai Toshiba-cho, Saiwai-ku, Kawasaki 210
Phone : +81-44-549-2238
EMail : jinmei@isl.rdc.toshiba.co.
Hiroshi
R&D Center,
1 Komukai Toshiba-cho, Saiwai-ku, Kawasaki 210
Phone : +81-44-549-2238
EMail : hiroshi@isl.rdc.toshiba.co.
Nagami, et. al. Informational [Page 19]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
