As per Relevance of the word redirect, we have this rfc below:
Network Working Group P. Newman,
Request for Comments: 1953 W. L. Edwards,
Category: Informational R. Hinden,
E. Hoffman,
F. Ching Liaw,
T. Lyon,
G. Minshall,
May 1996
Ipsilon Flow Management Protocol Specification for IPv
Version 1.0
Status of this
This document provides information for the Internet community.
memo does not specify an Internet standard of any kind.
of this memo is unlimited
IESG Note
This memo documents a private protocol for IPv4-based flows.
protocol is NOT the product of an IETF working group nor is it
standards track document. It has not necessarily benefited from
widespread and in depth community review that standards
documents receive
The Ipsilon Flow Management Protocol (IFMP), is a protocol
allowing a node to instruct an adjacent node to attach a layer 2
label to a specified IP flow. The label allows more efficient
to cached routing information for that flow. The label can
enable a node to switch further packets belonging to the
flow at layer 2 rather than forwarding them at layer 3.
Table of
1. Introduction....................................................2
2. Flow Types......................................................2
3. IFMP Adjacency Protocol.........................................4
3.1 Packet Format.............................................4
3.2 Procedure.................................................7
4. IFMP Redirection Protocol......................................10
4.1 Redirect Message.........................................12
4.2 Reclaim Message..........................................13
4.3 Reclaim Ack Message......................................15
4.4 Label Range Message......................................16
Newman, et. al. Informational [Page 1]
RFC 1953 IFMP Specification May 1996
4.5 Error Message............................................17
References........................................................19
Security Considerations...........................................19
Authors' Addresses................................................19
1.
The Ipsilon Flow Management Protocol (IFMP), is a protocol
instructing an adjacent node to attach a layer 2 label to a
IP flow. The label allows more efficient access to cached
information for that flow and it allows the flow to be
rather than routed in certain cases
If a network node's upstream and downstream links both redirect
flow at the node, then the node can switch the flow at the data
layer rather than forwarding it at the network layer. The
space is managed at the downstream end of each link and
messages are sent upstream to associate a particular flow with
given label. Each direction of transmission on a link is
separately
If the flow is not refreshed by the time the lifetime field in
redirect message expires, then the association between the flow
the label is discarded. A flow is refreshed by sending a
message, identical to the original, before the lifetime expires
Several flow types may be specified. Each flow type specifies
set of fields from the packet header that are used to identify
flow. There must be an ordering amongst the different flow
such that a most specific match operation may be performed
A particular flow is specified by a flow identifier. The
identifier for that flow gives the contents of the set of fields
the packet header as defined for the flow type to which it belongs
This document specifies the IFMP protocol for IPv4 on a point-to
point link. The definition of labels, and the encapsulation
flows, are specified in a separate document for each specific
link technology. The specification for ATM data links is given
[ENCAP].
2. Flow
A flow is a sequence of packets that are sent from a
source to a particular (unicast or multicast) destination and
are related in terms of their routing and any logical handling
they may require
Newman, et. al. Informational [Page 2]
RFC 1953 IFMP Specification May 1996
A flow is identified by its flow identifier
Several different flow types can be defined. The particular set
fields from the packet header used to identify a flow constitutes
flow type. The values of these fields, for a particular flow
constitutes the flow identifier for that flow. The values of
fields must be invariant in all packets belonging to the same flow
any point in the network
Flow types are sub- or super-sets of each other such that there is
clear hierarchy of flow types. This permits a most specific
operation to be performed. (If additional flow types are defined
the future that are not fully ordered then the required behavior
be defined.) Each flow type also specifies an encapsulation that
to be used after a flow of this type is redirected.
encapsulations for each flow type are specified in a
document for each specific data link technology. The
for flows over ATM data links are given in [ENCAP].
Three flow types are defined in this version of the protocol
Flow Type 0
Flow Type 0 is used to change the encapsulation of IPv4
from the default encapsulation
For Flow Type 0: Flow Type = 0 and Flow ID Length = 0.
The Flow Identifier for Flow Type 0 is null (zero length).
Flow Type 1
Flow Type 1 is designed for protocols such as UDP and TCP in
the first four octets after the IPv4 header specify a Source
number and a Destination Port number
For Flow Type 1, Flow Type = 1 and Flow ID Length = 4 (32
words).
The format of the Flow Identifier for Flow Type 1 is
Newman, et. al. Informational [Page 3]
RFC 1953 IFMP Specification May 1996
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| IHL |Type of Service| Time to Live | Protocol |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Port | Destination Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Flow Type 2
For Flow Type 2, Flow Type = 2 and Flow ID Length = 3 (32
words).
The format of the Flow Identifier for Flow Type 2 is
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| IHL | Reserved | Time to Live | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Reserved fields are unused and should be set to zero by
sender and ignored by the receiver
3. IFMP Adjacency
The IFMP Adjacency Protocol allows a host or router to discover
identity of a peer at the other end of a link. It is also used
synchronize state across the link, to detect when the peer at
other end of the link changes, and to exchange a list of IP
assigned to the link
3.1 Packet
All IFMP messages belonging to the Adjacency Protocol must
encapsulated within an IPv4 packet and must be sent to the IP
broadcast address (255.255.255.255). The Protocol field in the
header must contain the value 101 (decimal) indicating that the
packet contains an IFMP message. The Time to Live (TTL) field in
IP header must be set to 1.
Newman, et. al. Informational [Page 4]
RFC 1953 IFMP Specification May 1996
All IFMP messages belonging to the adjacency protocol have
following structure
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 | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sender Instance |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Peer Instance |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Peer Identity |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Peer Next Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Reserved | Max Ack Intvl |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Address List ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The IFMP protocol version number. The current Version = 1.
Op
Specifies the function of the message. Four Op Codes
defined for the IFMP Adjacency Protocol
SYN: Op Code = 0
SYNACK: Op Code = 1
RSTACK: Op Code = 2
ACK: Op Code = 3
The 16-bit one's complement of the one's complement sum
a pseudo header of information from the IP header and
IFMP message itself. The pseudo header,
prefixed to the IFMP message, contains the Source Address
the Destination Address, and the Protocol fields from
IPv4 header, and the total length of the IFMP
starting with the Version field (this is equivalent to
value of the Total Length field from the IPv4 header
the length of the IPv4 header itself).
Newman, et. al. Informational [Page 5]
RFC 1953 IFMP Specification May 1996
Sender
For the SYN, SYNACK, and ACK messages, is the sender'
instance number for the link. The receiver uses this
detect when the link comes back up after going down or
the identity of the peer at the other end of the
changes. The instance number is a 32 bit number that
guaranteed to be unique within the recent past and
change when the link or node comes back up after
down. It is used in a similar manner to the
sequence number (ISN) in TCP [RFC 793]. Zero is not
valid instance number. For the RSTACK message the
Instance field is set to the value of the Peer
field from the incoming message that caused an
message to be generated
Peer
For the SYN, SYNACK, and ACK messages, is what the
believes is the peer's current instance number for
link. If the sender of the message does not know
peer's current instance number for the link, the
must set this field to zero. For the RSTACK message
Peer Instance field is set to the value of the
Instance field from the incoming message that caused
RSTACK message to be generated
Peer
For the SYN, SYNACK, and ACK messages, is the IP address
the peer that the sender of the message believes is at
other end of the link. The Peer Identity is taken from
Source IP Address of the IP header of a SYN or a
message. If the sender of the message does not know the
address of the peer at the other end of the link,
sender must set set this field to zero. For the
message, the Peer Identity field is set to the value of
Source Address field from the IP header of the
message that caused an RSTACK message to be generated
Peer Next Sequence
Gives the value of the peer's Sequence Number that
sender of the IFMP Adjacency Protocol message expects
arrive in the next IFMP Redirection Protocol message. If
node is in the ESTAB state, and the value of the Peer
Sequence Number in an incoming ACK message is greater
the value of the Sequence Number plus one, from the
IFMP Redirection Protocol message transmitted out of
port on which the incoming ACK message was received,
link should be reset. The procedure to reset the link
defined in section 3.2.
Newman, et. al. Informational [Page 6]
RFC 1953 IFMP Specification May 1996
Max Ack
Maximum Acknowledgement Interval is the maximum amount
time the sender of the message will wait until
an ACK message
Address
A list of one or more IP addresses that are assigned to
link by the sender of the message. The list must have
least one entry that is identical to the Source Address
the IP header. The contents of this list are not used
the IFMP protocol but can be made available to the
protocol
3.2
The IFMP Adjacency Protocol is described by the rules and
tables given in this section
The rules and state tables use the following operations
o The "Update Peer Verifier" operation is defined as storing
Sender Instance and the Source IP Address from a SYN or
message received from the peer on a particular port
o The procedure "Reset the link" is defined as
1. Generate a new instance number for the
2. Delete the peer verifier (set the stored values of
Instance and Source IP Address of the peer to zero
3. Set Sequence Number and Peer Next Sequence Number to
4. Send a SYN
5. Enter the SYNSENT
o The state tables use the following Boolean terms and operators
A The Sender Instance in the incoming message matches
value stored from a previous message by the "Update
Verifier" operation for the port on which the
message is received
B The Sender Instance and the Source IP Address in
incoming message matches the value stored from a
message by the "Update Peer Verifier" operation for
port on which the incoming message is received
Newman, et. al. Informational [Page 7]
RFC 1953 IFMP Specification May 1996
C The Peer Instance and Peer Identity in the incoming
matches the value of the Sender Instance and the Source
Address currently in use for all SYN, SYNACK, and
messages transmitted out of the port on which the
message was received
"&&" Represents the logical AND
"||" Represents the logical OR
"!" Represents the logical negation (NOT) operation
o A timer is required for the periodic generation of SYN, SYNACK
and ACK messages. The period of the timer is unspecified but
value of one second is suggested
There are two independent events: the timer expires, and a
arrives. The processing rules for these events are
Timer Expires: Reset
If state = SYNSENT Send
If state = SYNRCVD Send
If state = ESTAB Send
Packet Arrives: If incoming message is an
If A && C && !
Reset the
Else Discard the
Else the following State Tables
o State synchronization across a link is considered to be
when a node reaches the ESTAB state
Newman, et. al. Informational [Page 8]
RFC 1953 IFMP Specification May 1996
State
State:
+======================================================================+
| Condition | Action | New State |
+====================+=====================================+===========+
| SYNACK && C | Update Peer Verifier; Send ACK | ESTAB |
+--------------------+-------------------------------------+-----------+
| SYNACK && !C | Send RSTACK | SYNSENT |
+--------------------+-------------------------------------+-----------+
| SYN | Update Peer Verifier; Send SYNACK | SYNRCVD |
+--------------------+-------------------------------------+-----------+
| ACK | Send RSTACK | SYNSENT |
+======================================================================+
State:
+======================================================================+
| Condition | Action | New State |
+====================+=====================================+===========+
| SYNACK && C | Update Peer Verifier; Send ACK | ESTAB |
+--------------------+-------------------------------------+-----------+
| SYNACK && !C | Send RSTACK | SYNRCVD |
+--------------------+-------------------------------------+-----------+
| SYN | Update Peer Verifier; Send SYNACK | SYNRCVD |
+--------------------+-------------------------------------+-----------+
| ACK && B && C | Send ACK | ESTAB |
+--------------------+-------------------------------------+-----------+
| ACK && !(B && C) | Send RSTACK | SYNRCVD |
+======================================================================+
State:
+=======================================================================+
| Condition | Action | New State |
+=====================+=====================================+===========+
| SYN || SYNACK | Send ACK (note 1) | ESTAB |
+---------------------+-------------------------------------+-----------+
| ACK && B && C | Send ACK (note 1) | ESTAB |
+---------------------+-------------------------------------+-----------+
| ACK && !(B && C) | Send RSTACK | ESTAB |
+=======================================================================+
Note 1: No more than one ACK should be sent within any time period
length defined by the timer
Newman, et. al. Informational [Page 9]
RFC 1953 IFMP Specification May 1996
4. IFMP Redirection
A sender encapsulates within an IPv4 packet all IFMP
belonging to the Redirection Protocol. The sender sends
messages to the unicast IP address of the peer at the other end
the link. The IP address of the peer is obtained from the
protocol. The Protocol field in the IP header must contain the
101 (decimal) indicating that the IP packet contains an IFMP message
The Time to Live (TTL) field in the IP header must be set to 1.
All IFMP Redirection Protocol messages have the following structure
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 | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sender Instance |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Peer Instance |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Message Body ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The IFMP protocol version number, currently Version = 1.
Op
This field gives the message type. Five message types
currently defined for the IFMP Redirection Protocol
REDIRECT: Op Code = 4
RECLAIM: Op Code = 5
RECLAIM ACK: Op Code = 6
LABEL RANGE: Op Code = 7
ERROR: Op Code = 8
The 16-bit one's complement of the one's complement sum
a pseudo header of information from the IP header, and
IFMP message itself. The pseudo header,
prefixed to the IFMP message, contains the Source Address
the Destination Address, and the Protocol fields from
Newman, et. al. Informational [Page 10]
RFC 1953 IFMP Specification May 1996
IPv4 header, and the total length of the IFMP
starting with the version field (this is equivalent to
value of the Total Length field from the IPv4 header
the length of the IPv4 header itself).
Sender
The sender's instance number for the link from the
Adjacency Protocol
Peer
What the sender believes is the peer's current
number for the link from the IFMP Adjacency protocol
Sequence
The sender must increment by one, modulo 2**32, for
IFMP Redirection Protocol message sent across a link.
allows the receiver to process IFMP Redirection
messages in order. The Sequence Number is set to zero
a node resets the link
Message
Contains a list of one or more IFMP Redirection
message elements. All of the message elements in the
have the same message type because the Op Code
applies to the entire IFMP message. The number of
elements included in a single packet must not cause
total size of the IFMP message to exceed the MTU size
the underlying data link. Only a single message element
permitted in a Label Range message or in an Error message
No IFMP Redirection Protocol messages can be sent across a link
the IFMP Adjacency Protocol has achieved state synchronization
that link. All IFMP Redirection Protocol messages received on a
that does not currently have state synchronization must be discarded
For every received IFMP Redirection Protocol message the
must check the Source IP Address from the IP header, the
Instance, and the Peer Instance. The incoming message must
discarded if the Sender Instance and the Source IP Address fields
not match the values stored by the "Update Peer Verifier"
of the IFMP Adjacency Protocol for the port on which the message
received. The incoming message must also be discarded if the
Instance field does not match the current value for the
Instance of the IFMP Adjacency Protocol
Newman, et. al. Informational [Page 11]
RFC 1953 IFMP Specification May 1996
4.1 Redirect
The Redirect Message element is used to instruct an adjacent node
attach one or more given labels to packets belonging to one or
specified flows each for a specified period of time. The
message is not acknowledged
Each Redirect message element has the following structure
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flow Type | Flow ID Length| Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Flow Identifier ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Flow
Specifies the Flow Type of the flow identifier contained
the Flow Identifier field
Flow ID
Specifies the length of the Flow Identifier field
integer multiples of 32 bit words
Lifetime
Specifies the length of time, in seconds, for which
redirection is valid. The association of flow
and label should be discarded at a time no greater
that specified by the Lifetime field. A value of zero
not valid
Label
Contains a 32 bit label. The format of the label
dependent upon the type of physical link across which
Redirect message is sent. (The format of the label for
data links is specified in [ENCAP].)
Flow
Identifies the flow with which the specified label
be associated. The length of the Flow Identifier
must be an integer multiple of 32 bit words to preserve 32
bit alignment
Newman, et. al. Informational [Page 12]
RFC 1953 IFMP Specification May 1996
A node can send an IFMP message containing one or more
message elements across a link to its upstream neighbor.
Redirect message element requests that the upstream
associate a given link-level label to packets belonging to
specified flow for up to a specified period of time. A
receiving an IFMP message that contains one or more Redirect
elements from an adjacent downstream neighbor can choose to
any or all of the Redirect message elements. Neither the
message nor any of the Redirect message elements are acknowledged
If the node chooses to accept a particular Redirect message
and to redirect the specified flow, it should attach the
specified in the Redirect message element to all further packets
on that flow until it chooses to do so no longer, or until
specified lifetime expires. While the flow remains redirected,
encapsulation specified by the definition of the Flow Type given
the Redirect message element must be used for all packets
to that flow. If the label in a Redirect message element is
the range that can be handled across the relevant link, a Label
message can be returned to the sender. The Label Range
informs the sender of the Redirect message of the range of
that can be sent across the link
If a Redirect message element is received specifying a flow that
already redirected, the Label field in the received Redirect
element must be checked against the label stored for the
flow. If they agree, the lifetime of the redirected flow is reset
that contained in the Redirect message element. If they disagree
the Redirect message element is ignored, and the flow returned to
default state. There is a minimum time between Redirect
elements specifying the same flow. The default value is one second
If a receiving node detects an error in any of the fields of
Redirect message element, the node must discard that message
without affecting any other Redirect message elements in the
IFMP message. The receiver should return an error message to
sender only in the case that the receiver does not understand
version of the IFMP protocol in the received IFMP message or does
understand a Flow Type in any of the Redirect message elements.
Error Message should be returned for each Flow Type that is
understood
4.2 Reclaim
The Reclaim message element is used by a node to instruct an
upstream node to unbind one or more flows from the labels to
they are currently bound, and to release the labels
Newman, et. al. Informational [Page 13]
RFC 1953 IFMP Specification May 1996
Each Reclaim message element has the following structure
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flow Type | Flow ID Length| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Flow Identifier ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Flow
Specifies the Flow Type of the Flow Identifier contained
the Flow ID field
Flow ID
Specifies the length of the Flow Identifier field
integer multiples of 32 bit words
Field is unused and should be set to zero by the sender
ignored by the receiver
Field contains the label to be released
Flow
Field contains the flow identifier to be unbound
A node can send a Reclaim message element to instruct an
upstream node to unbind a flow from the label to which it
currently bound, return the flow to the default forwarding state,
release the label. Each Reclaim message element applies to a
flow and a single label. When the receiver has completed
operation, it must issue a Reclaim Ack message element. Reclaim
message elements can be grouped together, in any order, into one
more IFMP Reclaim Ack messages and returned to the sender as
acknowledgment that the operation is complete
If a Reclaim message element is received indicating an unknown flow
a Reclaim Ack message element must be returned containing the
Label and Flow Identifier fields from the Reclaim message
Newman, et. al. Informational [Page 14]
RFC 1953 IFMP Specification May 1996
If a Reclaim message element is received indicating a known flow,
with a Label that is not currently bound to that flow, the flow
be unbound and returned to the default forwarding state, and
Reclaim Ack message sent containing the actual label to which
flow was previously bound
If the receiver detects an error in any of the fields of a
message element, the receiver must discard that message element
without affecting any other Reclaim message elements in the
message. The receiver must return an error message to the
only in the case that the receiver does not understand the version
the IFMP protocol in the received message or does not understand
Flow Type in one of the Reclaim message elements
4.3 Reclaim Ack
The Reclaim Ack message element is used by a receiving node
acknowledge the successful release of one or more reclaimed labels
Each Reclaim Ack message element has the following structure
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flow Type | Flow ID Length| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Flow Identifier ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Flow
Specifies the Flow Type of the Flow Identifier contained
the Flow Identifier field
Flow ID
Specifies the length of the Flow Identifier field
integer multiples of 32 bit words
Field is unused and should be set to zero by the sender
ignored by the receiver
Field contains the label released from the flow
by the Flow Identifier
Newman, et. al. Informational [Page 15]
RFC 1953 IFMP Specification May 1996
Flow
Field contains the Flow Identifier from the Reclaim
element that requested the release of the label
in the Label field
A Reclaim Ack message element must be sent in response to
Reclaim message element received. It is sent to indicate that
requested flow is now unbound and that the label is now free.
possible, each Reclaim Ack message element should not be sent
all data queued for transmission on the link, using the
specified for release, has been sent
If a Reclaim Ack message element is received specifying a flow
which no Reclaim message element was issued, that Reclaim Ack
element must be ignored, but no other Reclaim Ack message elements
the same message must be affected
If a Reclaim Ack message element is received specifying a
label from the one sent in the original Reclaim message element
that flow, the Reclaim Ack message element should be handled as
the reclaim operation were successful
If an error is detected in any of the fields of a Reclaim Ack
element, that message element must be discarded, but no other
Ack message elements in the same message must be affected
The receiver should return an Error message to the sender only in
case that the receiver does not understand the version of the
protocol in the received message or does not understand a Flow
in one of the Reclaim Ack message elements
4.4 Label Range
The Label Range message element is sent in response to a
message if the label requested in one or more of the Redirect
elements is outside the range that the receiver of the
message can handle. The Label Range message informs the sender
the Redirect message of the label range that can be handled on
relevant link
Only a single Label Range message element is permitted in a
Range message. The Label Range message element has the
structure
Newman, et. al. Informational [Page 16]
RFC 1953 IFMP Specification May 1996
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Minimum Label |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Maximum Label |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Minimum
The minimum value of label that can be specified in an
Redirection Protocol message across this link
Maximum
The maximum value of label that can be specified in an
Redirection Protocol message across this link
All values of label within the range Minimum Label to Maximum
inclusive may be specified in an IFMP Redirection Protocol
across the link
4.5 Error
An Error message can be sent by a node in response to any
Redirection Protocol message
Only a single Error message element is permitted in an Error message
The Error message element has the following structure
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Error Code | Parameter |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Error
Specifies which an error has occurred
Each Error message can specify a single Parameter
Newman, et. al. Informational [Page 17]
RFC 1953 IFMP Specification May 1996
Two Error message elements are specified
Bad Version
Error Code = 1. The sender of the Error message cannot process
version of the IFMP protocol of the message that caused
error. This message must only be sent if the version
the message that caused the error is greater than the
recent version that the sender of the Error message
process. The parameter field of this Error message
the most recent version of the IFMP protocol that
sender can process, right justified, with the unused
significant bits of the Parameter field set to zero
Bad Flow Type
Error Code = 2. The sender of the Error message does not understand
Flow Type that was received in the message that caused
error. The Flow Type that caused the error is given in
parameter field, right justified, with the unused
significant bits of the Parameter field set to zero
Newman, et. al. Informational [Page 18]
RFC 1953 IFMP Specification May 1996
[ENCAP] Newman, P., et. al., "Transmission of Flow Labelled IPv
on ATM Data Links Ipsilon Version 1.0," Ipsilon Networks
RFC 1954, May 1996.
[RFC793] Postel, J., "Transmission Control Protocol," STD 7,
793, September 1981.
SECURITY
Security issues are not discussed in this memo
AUTHORS'
Peter Newman Phone: +1 (415) 846-4603
Ipsilon Networks, Inc. EMail: pn@ipsilon.
W. L. Edwards, Chief Scientist Phone: +1 (913) 534 5334
Sprint EMail: texas@sprintcorp.
Robert M. Hinden Phone: +1 (415) 846-4604
Ipsilon Networks, Inc. EMail: hinden@ipsilon.
Eric Hoffman Phone: +1 (415) 846-4610
Ipsilon Networks, Inc. EMail: hoffman@ipsilon.
Fong Ching Liaw Phone: +1 (415) 846-4607
Ipsilon Networks, Inc. EMail: fong@ipsilon.
Tom Lyon Phone: +1 (415) 846-4601
Ipsilon Networks, Inc. EMail: pugs@ipsilon.
Greg Minshall Phone: +1 (415) 846-4605
Ipsilon Networks, Inc. EMail: minshall@ipsilon.
Newman, et. al. Informational [Page 19]
RFC 1953 IFMP Specification May 1996
Ipsilon Networks, Inc. is located at
2191 East Bayshore
Suite 100
Palo Alto, CA 94303
Sprint is located at
Sprint Technology Services - Long Distance
9300 Metcalf
Mailstop KSOPKB0802
Overland Park, KS 66212-6333
Newman, et. al. Informational [Page 20]
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
