Internet DRAFT - draft-dubois-r2cp
draft-dubois-r2cp
Internet Engineering Task Force D. Dubois, Ed.
Internet-Draft General Dynamics C4 Systems
Intended status: Informational A. Kovummal
Expires: September 3, 2011 Juniper Networks
B. Petry
L-3 Communications
B. Berry
Cisco Systems
March 2, 2011
Radio-Router Control Protocol (R2CP)
draft-dubois-r2cp-00
Abstract
This document describes a protocol that allows a router to learn the
performance characteristics of the network to its neighbors when the
shared media link between them may provide highly dynamic bandwidth
characteristics. This information comes from the radio modems which
are providing periodic updates about the quality of the radio signal
to the routers listening for these updates on the same physical
network segment. The functionality is similar to that described in
"PPPoE Extensions for Credit Flow and Link Metrics" [RFC5578] but
applied to a local area network topology rather than a set of point-
to-point links.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
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."
This Internet-Draft will expire on September 3, 2011.
Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved.
Dubois, et al. Expires September 3, 2011 [Page 1]
Internet-Draft Radio-Router Control Protocol (R2CP) March 2011
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Dubois, et al. Expires September 3, 2011 [Page 2]
Internet-Draft Radio-Router Control Protocol (R2CP) March 2011
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 5
2. Underlying SATCOM Topology . . . . . . . . . . . . . . . . . . 5
2.1. Transmission Subsystem (TS) Interface . . . . . . . . . . 5
3. Radio Router Control Protocol (R2CP) . . . . . . . . . . . . . 6
4. Protocol Specification . . . . . . . . . . . . . . . . . . . . 9
4.1. R2CP Control Header . . . . . . . . . . . . . . . . . . . 10
4.2. Node Level Messages . . . . . . . . . . . . . . . . . . . 12
4.2.1. Modem Initiate Message (MIM) . . . . . . . . . . . . . 12
4.2.2. Router Offer Message (ROM) . . . . . . . . . . . . . . 15
4.2.3. Node Heartbeat Message (NHB) . . . . . . . . . . . . . 17
4.2.4. Node Terminate Message (NTM) . . . . . . . . . . . . . 19
4.2.5. Node Terminate ACK Message (NTA) . . . . . . . . . . . 21
4.3. Session Level Messages . . . . . . . . . . . . . . . . . . 23
4.3.1. Session Initiate Message (SIM) . . . . . . . . . . . . 23
4.3.2. Session Initiate ACK Message (SIA) . . . . . . . . . . 25
4.3.3. Session Update Message (SUM) . . . . . . . . . . . . . 27
4.3.4. Session Terminate Message (STM) . . . . . . . . . . . 32
4.3.5. Session Terminate ACK Message (STA) . . . . . . . . . 34
4.4. R2CP Type-Length-Value (TLV) Definitions . . . . . . . . . 36
4.4.1. Node Heartbeat Interval TLV . . . . . . . . . . . . . 37
4.4.2. Return Status TLV . . . . . . . . . . . . . . . . . . 38
4.4.3. Remote MAC Address TLV . . . . . . . . . . . . . . . . 39
4.4.4. Reserved (VLAN) TLV . . . . . . . . . . . . . . . . . 39
4.4.5. Session ID TLV . . . . . . . . . . . . . . . . . . . . 39
4.4.6. RLQ Metric TLV . . . . . . . . . . . . . . . . . . . . 40
4.4.7. Resource Metric TLV . . . . . . . . . . . . . . . . . 40
4.4.8. Latency Metric TLV . . . . . . . . . . . . . . . . . . 41
4.4.9. Current Data Rate Metric TLV . . . . . . . . . . . . . 41
4.4.10. Maximum Data Rate Metric TLV . . . . . . . . . . . . . 42
4.5. Data Smoothing . . . . . . . . . . . . . . . . . . . . . . 42
5. OSPF Link Cost Assignments . . . . . . . . . . . . . . . . . . 43
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 45
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 45
7.1. R2CP Port Number . . . . . . . . . . . . . . . . . . . . . 45
7.2. R2CP Code Definitions . . . . . . . . . . . . . . . . . . 45
7.3. R2CP TLV Type Definitions . . . . . . . . . . . . . . . . 46
7.4. R2CP Error Code Definitions . . . . . . . . . . . . . . . 47
8. Security Considerations . . . . . . . . . . . . . . . . . . . 47
9. Open Source Implementation . . . . . . . . . . . . . . . . . . 47
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 48
10.1. Normative References . . . . . . . . . . . . . . . . . . . 48
10.2. Informative References . . . . . . . . . . . . . . . . . . 48
Appendix A. Terms and Definitions . . . . . . . . . . . . . . . . 48
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 49
Dubois, et al. Expires September 3, 2011 [Page 3]
Internet-Draft Radio-Router Control Protocol (R2CP) March 2011
1. Introduction
This document describes a protocol that is to be used between two or
more nodes of a Local Area Network (LAN) which supports access to a
SATCOM network. The nodes communicate with each other over a
physical network segment and consist of radio modems connected to an
over-the-air network and routers providing connectivity to other
networks. The basic topology is illustrated in Figure 1.
The protocol enables a nearby router to provide connectivity to and
through remote routers by forwarding traffic to the radio that has
joined the over-the-air network. The router learns about the
presence of remote routers of the same logical network and the
strength of the radio link between them based on information that is
exchanged between the radio and the router. The router incorporates
this information into its routing tables and makes its forwarding
decisions based on the queueing capacity of the radio and the quality
of the over-the-air signal between the neighbors that make up the
logical network.
|-----Local Neighbor----| |-----Remote Neighbor---|
+--------+ +-------+ +-------+ +--------+
| Router |======| Radio |----RF----| Radio |======| Router |
| Server | | Client| Link | Client| | Server |
+--------+ +-------+ +-------+ +--------+
| | | | | |
|-R2CP-| |----RLP---| |-R2CP-|
| |
|----------- Logical Network ------------|
Figure 1: R2CP Network
As mentioned earlier, the relationship between the network elements
is very similar to that described in [RFC5578] for point-to-point
connections supported by PPPoE sessions. The user-configured
parameters and metrics of the session update messages are shared
between the two protocols. The key distinction is that the logical
network link in this case is a shared medium and allows a broadcast
or multicast transmission to be received by all neighbors. This is
in contrast to the strict one-to-one relatioship between neighbors in
the point-to-point topology.
The document starts off with a brief description of the SATCOM
network. The majority of the document describes the protocol between
the radio and router that allows the router to learn about the signal
quality of the over-the-air link from the radio. It also includes a
Dubois, et al. Expires September 3, 2011 [Page 4]
Internet-Draft Radio-Router Control Protocol (R2CP) March 2011
description on how the information from the radio can be used to
influence the link costs assigned to an Interior Gateway Protocol
such as OSPF.
1.1. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
2. Underlying SATCOM Topology
This section provides a brief description of the network topology
that can be used by this protocol to support. The satellite network
is made up of a partial mesh of routers connected via Radio Frequency
(RF) links provided by the Transmission Subsystem (TS). A design
characteristic of the overall network is to uniquely distinguish the
router function from the radio section, separating the Layer 3
routing from the Layer 2 transmission capabilities. The router and
radio are separate network nodes which are connected to each other
over a Local Area Network (LAN). With this decision, the interface
between the components becomes a critical function of the design.
This section provides an overview on the interface requirements of
the transmission subsystem and router.
2.1. Transmission Subsystem (TS) Interface
The Router and Radio use the Radio Router Control Protocol (R2CP) to
regulate data traffic flow from Router to Radio and for the Radio to
provide radio link information to the Router that are required for
its routing decisions.
An "R2CP Node" is either the local Router or the local Radio.
The "R2CP Peer" of the local Router is the local Radio and the R2CP
Peer of the local Radio is the local Router. The R2CP messages are
exchanged between these peers.
An "R2CP Neighbor" is either the remote Router or remote Radio. The
R2CP Neighbor of the local Radio is the remote Radio. The R2CP
Neighbor of the local Router is the remote Router.
An "R2CP Association" occurs after a successful MIM/ROM exchange
between the local Radio and local Router. It continues as long as
each peer is aware of the existence of the other by receiving
continuous confirmation that the other peer can communicate though
Dubois, et al. Expires September 3, 2011 [Page 5]
Internet-Draft Radio-Router Control Protocol (R2CP) March 2011
heartbeat messages.
The Router creates or tears down virtual interfaces on the physical
interface connecting the Radio automatically as Radio peers join or
dispatch. The Radio will use queue controllers on each virtual
interface which are directly managed by the Router according to pre-
defined profiles and have been configured by the user.
The Router shall assign unique identifiers to all virtual interfaces
and queue controllers.
Radio management traffic is logically separated from the data plane
and control plane. As an example, VLAN 51 is dedicated for local
radio management, and all local radio management related traffic will
be tagged with 802.1Q VLAN ID of 51. The radios do not communicate
with each other over 802.1Q VLAN 51; it is only used for local radio
management.
R2CP management traffic is logically separated from the data traffic.
For example, the R2CP Node and Session messages are sent on VLAN 52
and this VLAN is local between the radion and the router.
Each RF link is managed individually by the radios. Each RF
connection has its own link characteristics in terms of bandwidth,
latency and link connectivity that the Router considers for routing
traffic, regulating traffic flow, and managing priority queues. Each
radio system provides its own mechanism to update the Router on RF
link characteristics.
3. Radio Router Control Protocol (R2CP)
R2CP is a new protocol to provide flow control and radio link metrics
on an Ethernet network. The Radio uses a Session Initiate Message to
initialize sessions between itself and its directly-connected router.
RF link quality information and flow control status is conveyed from
the Radio to its local Router by the Session Update Message.
The Radio provides link metrics such as Current Data Rate, Maximum
Data Rate, Latency, Relative Link Quality and Resources to the
Router. The Router in turn uses this information to dynamically
change the link cost and rate shaping based on real-time link
performance.
There are five node level message types defined by this protocol,
used to establish and maintain the R2CP association between the radio
and router nodes on the physical network segment.
Dubois, et al. Expires September 3, 2011 [Page 6]
Internet-Draft Radio-Router Control Protocol (R2CP) March 2011
o The Modem Initiate Message (MIM) is used by the Radio to detect
R2CP capable routers and to negotiate node parameters between the
pair.
o The Router Offer Message (ROM) is sent by the Router in response
to a MIM and to acknowledge Node parameters.
o Node Heartbeat Messages are sent by both the Router and Radio once
an R2CP association has been formed and is used to monitor the
availability of the other node.
o The Node Terminate Message is used by either the Router or Radio
to terminate the R2CP neighbor association and close all
established R2CP sessions.
o The Node Terminate ACK Message is an optional message to
acknowledge receipt of the Node Terminate Message.
There are five session level message types defined by this protocol.
These allow neighboring R2CP Routers to discover each other and to
learn about the quality of the over-the-air link between them.
o The Session Initiate Message is sent by the local Radio to request
its local Router to set up a session for a new remote Router.
o Session Initiate Messages are acknowledged by the Router using a
Session Initiate ACK Message.
o The Session Update Message is similar to the PADQ packet described
in [RFC5578] and is periodically sent by the local Radio to keep
the local Router informed on the quality of the RF link towards
the remote Router.
o The Session Terminate Message is sent by either the Radio or
Router to terminate an existing session in order to free up system
resources once a remote node has logged off the network.
o Session Terminate Messages are acknowledged using the Session
Terminate ACK Message.
The node-level and session-level message are exchanged between
adjacent R2CP nodes and do not traverse the over-the-air link.
Figure 2 shows a sample packet flow between one Radio and one Router
to establish reachability with one remote router.
Dubois, et al. Expires September 3, 2011 [Page 7]
Internet-Draft Radio-Router Control Protocol (R2CP) March 2011
(cloud) Radio Router
| |
Radio establishes membership | |
in over-the-air network --~--> | |
| |
Modem Init (MIM) +------------> |
| <------------+ Router Offer (ROM)
| : |
Node Heartbeat +------------> |
| : |
| <------------+ Node Heartbeat
Radio discovers a neighbor | : |
and starts to establish an : :
R2CP session with --~--> | |
the Router | |
Session Init +------------> |
| <------------+ Session Init ACK
Session Update +------------> |
| |
<========= data ===>+<====>
| |
Session Update +------------> |
| |
<========= data ===>+<====>
| |
Session Term +------------> |
| <------------+ Sess Term ACK
| : |
Node Term +------------> |
| <------------+ Node Term ACK
| |
Figure 2: R2CP Packet Flow Sequence
During the Radio and Router MIM/ROM exchange, the Radio informs the
Router about the heartbeat interval.
Once the Radio has learned the MAC address of a distant Router in the
same over-the-air network, it sends a Session Initiate Message back
to its local Router to initiate a new R2CP session for the remote
router's MAC address (Mote that routers are identified by their MAC
addresses. Network-layer addresses addresses are not referenced).
The local Router generates a session ID for the referenced MAC
address and includes this value in a Session Initiate ACK Message
that is sent back to the local Radio. The session ID identifies a
unique router transmit queue associated with the unique MAC address
for a distant Radio or in the case of multicast destinations,
multiple distant radios. The session ID is a 16-bit number that the
Dubois, et al. Expires September 3, 2011 [Page 8]
Internet-Draft Radio-Router Control Protocol (R2CP) March 2011
Router uses to uniquely identify each discovered unicast or multicast
neighbor or broadcast traffic for all remote nodes in the over-the-
air network. A single session ID value is sufficient for multicast
destination addresses since the Radio is responsible for forwarding
the packet to multiple receivers once it reaches the over-the-air
link.
The Router interface that communicates with the radio will be a
virtual interface that receives the Session Update Message with a
Link Quality Metric (LQM). The Router will provide packet queuing
and routing policy for packets in each session on that virtual
interface, independent of other virtual interfaces. The LQM includes
current and theoretical maximum outbound data rate and packet latency
(queuing and RF propagation delay).
The Radio communicates per-session flow control status in Session
Update Messages that it sends to the router using a rate-based
mechanism. In R2CP, flow control applies to the flow of data from
the Router to the Radio only. The Router does not attempt to limit
the flow of data from the Radio.
4. Protocol Specification
R2CP uses UDP as the transport layer protocol between the Radio and
Router. R2CP implementations compliant with this specification shall
support IPv4 for the IP layer.
The Time To Live (TTL) on all R2CP messages shall be set to 1. The
receiver should test that incoming packets do not have an invalid TTL
in order to reduce the risk of acting upon forged messages sent by a
more distant network.
The R2CP participants use a standard client-server model to
communicate with each other. The Router, acting as the server,
listens on a registered port for messages transmitted by the Radio.
The Radio, as its client, selects an unreserved UDP port as its
source and uses the registered UDP port number as the destination.
The Router sends its responses to the Radio by exchanging source and
destination port numbers. The registered UDP port number is
specified in Section 7.1.
The Router shall use the Radio's network layer address and UDP port
to discriminate adjacencies and associated sessions. The Router may
have multiple independent conversations with a single radio. The
Radio may have multiple routers connected to it as well.
The Router shall be able to be configured to enable or disable R2CP.
Dubois, et al. Expires September 3, 2011 [Page 9]
Internet-Draft Radio-Router Control Protocol (R2CP) March 2011
The means by which the user configures the Radio and Router is beyond
the scope of this document.
An R2CP association is established when the Radio sends a MIM and the
Router responds with a ROM such that the fields in both messages are
valid. An R2CP association is terminated when either R2CP node sends
a Node Terminate Message or, if the configured heartbeat interval is
greater than zero, if the R2CP node fails to receive three successive
Node Heartbeat messages from its R2CP peer. The current R2CP
association period is the time interval between when R2CP association
is established and R2CP is terminated.
The Router should report an error and include a Return Status TLV in
any R2CP response message transmitted to the Radio if the previous
R2CP message from the Radio is 802.1Q VLAN-tagged differently from
the MIM during the current R2CP association period.
4.1. R2CP Control Header
R2CP uses UDP as its transport protocol. All messages start with a
common control header structure that consists of the following
fields:
o The first 4 bits of the control header are the version number that
the sender is requesting to use. This document defines "version
zero" of the R2CP protocol. Control headers of all future
versions will have at least the fields described in this section
laid out in the same manner so that two nodes which are running
different versions of the protocol will be able to interoperate.
The node receiving an R2CP message where the version number is
greater than what it recognizes SHOULD NOT discard the packet or
log an error.
o The Control Flags field shall be the second 4 bits in the R2CP
header, with the bits named as follows from most to least
significant: Reserved 0, Reserved 1, Reserved 2 and Reserved 3.
By default the Control Flags field shall be set to 0x0. If any of
the Reserved 0, Reserved 1, Reserved 2 and Reserved 3 bits of the
Control Header are set, the message is considered malformed and
shall be ignored.
o The Code field shall be the second 8 bits in the R2CP header with
the value indicating the R2CP message type. Received messages
where the code value is either 0x00 or not defined shall be
ignored. The initial set of code values are specified in Table 12
o The Identifier Number field shall be an unsigned 16-bit integer in
the second 16 bits in the R2CP header. The field is used to match
Dubois, et al. Expires September 3, 2011 [Page 10]
Internet-Draft Radio-Router Control Protocol (R2CP) March 2011
up R2CP MIM and request messages with the corresponding ROM and
acknowledgements. In all other messages the Radio and Router do
not coordinate their Identifier Numbers - they are completely
independent.
For convenience and to ease troubleshooting, it is beneficial for
Identifier Number of the MIM and ROM messages to be set to 1 and
increase monotonically for each new R2CP message for the life of
the association and rolling over to zero after Identifier Number
65535 but implementations are not required to do so. No error is
declared if the Identifier Number in a received R2CP message is
less than the value in preceding messages.
The Identifier Number is not related to the Session number in any
way. This is to allow bundling of multiple sets of data values
for different sessions in a single Session Update message.
The Identfier number in retransmitted messages may be the re-used
from the original request or may increment like standard messages.
This is strictly an implemtation decision.
If the Radio or Router receives a ROM or acknowledgement message
which contains a Identifier Number which does not correspond to
the Identifier Number in an originate message (see Table 12) for
which a response message (see Table 12) has not been received, the
device should report an error.
o The Payload Length shall represent the total number of octets that
follow the R2CP Control Header. The octets associated with
Control Header are not included in the count.
R2CP messages shall always be transmitted, regardless of whether the
flow of data traffic from Router to Radio is currently restricted or
not.
A sample R2CP Control Header is shown below in Figure 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ver=0 | Rsvd | Code | Identifier Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| R2CP Payload Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: R2CP Control Header
R2CP has eleven message types as shown in Table 12. These messages
Dubois, et al. Expires September 3, 2011 [Page 11]
Internet-Draft Radio-Router Control Protocol (R2CP) March 2011
are also broken down into two types: node level messages and session
level messages. Each of these messages are defined in the following
sections.
Throughout the remainder of this section, incoming messages can
classified as "valid", "invalid" or "unrecognized". A valid R2CP
message is one of the standard R2CP message types (MIM, ROM, NHB,
NTM, NTA, SIM, SIA, SUM, STM, STA) that does not have any errors in
it. An invalid R2CP message is one of the standard message types
that is malformed or unsolicited that contains errors. Possible
errors are:
o Unsupported control flag set (6)
o Invalid payload length (7)
o Omitted mandatory TLVs (8)
o Disallowed TLVs (9)
o Invalid TLV length (10)
o Invalid TLV value(s) (11)
An unrecognized message is a message that is NOT one of the standard
R2CP message types regardless if it has errors or not.
4.2. Node Level Messages
The purpose of the node level messages is to configure operational
parameters for the current R2CP association period and manage the
association. The functions to manage the association include:
o Determine when to initiate an association
o Establish an association
o Maintain an association
o Determine when to terminate an association
There is a separate R2CP association per radio/router pairing. For
example, if there are two modems in one radio, then there will be two
separate MIM/ROM exchanges between the Radio and the Router.
4.2.1. Modem Initiate Message (MIM)
The Radio sends the MIM to establish R2CP association with the Router
and configure operational parameters. The MIM is sent whenever R2CP
association is not established, i.e. when the Radio is first
initialized or after R2CP association is terminated via Node
terminate or Heartbeat loss. In the case when a Radio is started
before the Router, the Radio will continuously send the MIM until the
Router responds with a ROM. In the case where a Router is powered
off after the MIM/ROM exchange is complete, the node heartbeat will
expire and the Radio will terminate the link. The Radio will then
Dubois, et al. Expires September 3, 2011 [Page 12]
Internet-Draft Radio-Router Control Protocol (R2CP) March 2011
begin to send the MIM again until the Router responds. In the event
the nodal association is lost, the Radio requests a new association
be established with the Router by transmitting a new MIM.
When the Radio has established its presence within the radio network
but does not have an active association with a Router, the Radio
shall send the Modem Initiate Message (MIM) every N seconds, where N
is a user-configurable value ranging from 1 to 60 seconds with a
default value of 5, until a valid ROM is received.
The Radio continues sending MIMs at a predefined interval until a
valid ROM is received. While waiting for that ROM, the Radio does
not send any other R2CP messages.
The Radio shall set the destination address of its MIMs to the
Router's network layer address as configured by the user or to the
subnet broadcast address of the interface on which the R2CP protocol
is activated.
The Router must respond to the Radio with a ROM. When the Radio and
Router are capable of supporting different versions of the protocol,
the conversation between the two devices should agree to use the
version which is common to both which will be the lower version
number.
The MIM shall include the Heartbeat Interval TLV. The Router shall
set its node heartbeat interval to the value in the MIM Heartbeat
Interval TLV.
The Router shall consider a received MIM invalid if any of the
following conditions are true and should report an invalid MIM and
the condition, and send a ROM containing a Return Status TLV with the
Return Code field set to the value in parenthesis following the
condition:
o Unsupported control flag set (6)
o Invalid payload length (7)
o Omitted mandatory TLVs (8)
o Disallowed TLVs (9)
o Invalid TLV length (10)
o Invalid TLV value(s) (11)
If there is no R2CP adjacency established, the Radio whall attempt to
establish the R2CP adjacency by sending a MIM at the pre-defined
interval.
If there is no R2CP adjacency established and the Router receives an
invalid R2CP message, the Router should report an invalid R2CP
Dubois, et al. Expires September 3, 2011 [Page 13]
Internet-Draft Radio-Router Control Protocol (R2CP) March 2011
message type and should send a ROM containing a Return Status TLV
with the Return Code field set to (3).
If there is no R2CP adjacency established and the Router receives a
valid R2CP message other than a MIM, the Router should report an R2CP
message type was received which was an invalid type for the current
R2CP state, and should send a ROM containing a Return Status TLV with
the Return Code field set to (4).
When the Radio receives a Node Terminate, the radio shall send a Node
Terminate ACK and then start sending a MIM at its configured MIM
transmit rate to re-establish the R2CP relationship.
If the Router believes that it already has an existing R2CP
association with a Radio and receives a valid MIM from the Radio's
network layer address (e.g.: the Radio has reset), the Router shall
send a Node Terminate to the Radio.
As described in Section 4.2.5, when the Radio receives a Node
Terminate, it should send a Node Terminate ACK and then start send a
MIM at its configured MIM transmit rate to re-establish the R2CP
adjacency.
See Table 14 for a complete list of Return Codes.
The MIM shall have the following Mandatory TLV's:
1) Node Heartbeat Interval TLV
The MIM has the following Optional TLV's:
1) None
The MIM with mandatory TLV's is depicted in Figure 4. A description
of the attributes of the Modem Initiate Message is contained in
Table 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ver=0 | Rsvd | Code = 1 | Identifier Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Payload Length = 4 | TLV Type = 1 | TLV Length = 2|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Heartbeat Interval |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: R2CP Modem Initiate Message
Dubois, et al. Expires September 3, 2011 [Page 14]
Internet-Draft Radio-Router Control Protocol (R2CP) March 2011
+------------+------------+--------+-------+------------------------+
| Attribute | Mandatory/ | Length | Value | Description |
| | Optional | (bits) | | |
+------------+------------+--------+-------+------------------------+
| Version | Mandatory | 4 | 0 | Version number |
| Reserved | Mandatory | 4 | 0 | Reserved for future |
| | | | | use |
| Code | Mandatory | 8 | 1 | Modem Initiate Message |
| Identifier | Mandatory | 16 | | R2CP packet identifier |
| R2CP Len | Mandatory | 16 | 4 | Length of packet |
| | | | | excluding header |
| TLV Code | Mandatory | 8 | 1 | Heartbeat Interval TLV |
| TLV Len | Mandatory | 8 | 2 | Length of TLV Payload |
| TLV Value | Mandatory | 16 | 0-60 | Node Heartbeat |
| | | | | Interval in seconds |
+------------+------------+--------+-------+------------------------+
Table 1: R2CP Modem Initiate Message Values
4.2.2. Router Offer Message (ROM)
The Router Offer Message (ROM) is sent from the Router to the Radio
in response to the Modem Initiate Message. A Router receiving a
valid broadcast MIM shall respond with a unicast ROM. In the event
the Router received an invalid MIM, it may respond with a ROM and
include a Return Status TLV for each of the MIM field values which
are incorrect or incompatible.
The Router does not require that the ROM be acknowledged.
The Identifier Number in the Control Header of the ROM shall be the
same as the Identifier Number field in the MIM it is responding to.
The Router shall set its Heartbeat Interval to match the valid
heartbeat interval provided in the MIM.
As described in Section 4.2.1 the Radio and Router need to agree on
which version of the protocol is to be used for the duration of the
R2CP association between the two nodes.
An invalid ROM is defined as any malformed or unsolicited ROM message
received either by the Radio or Router.
The Radio shall consider a received ROM invalid if any of the
following conditions are true and should report an invalid ROM and
the invalid condition:
Dubois, et al. Expires September 3, 2011 [Page 15]
Internet-Draft Radio-Router Control Protocol (R2CP) March 2011
o Unsupported control flag set
o Invalid Identifier Number, i.e. not equal to the Identifier Number
sent in the previous MIM
o Invalid payload length
o Undefined TLVs
o Disallowed TLVs
o Invalid TLV length
o Invalid TLV value(s)
o Received when the Radio believes an adjacency already exists (that
is, an unsolicited ROM).
If there is no R2CP adjacency established and the Radio receives an
invalid R2CP message type, the Radio should report it received an
invalid R2CP message type.
If there is no R2CP adjacency established and the Radio receives a
valid message type other than a ROM, it should report an R2CP message
type was received which was an invalid type for the current R2CP
state.
If there is an R2CP adjacency established and the Radio receives an
invalid ROM, the Radio shall ignore the ROM, should report it
received an invalid R2CP message, and then terminate the R2CP
association by sending a Node Terminate Message. After the Node
Terminate ACK Message has been received or the R2CP association with
the Router has been terminated, the Radio will need to re-establish
the R2CP association as normal by sending a MIM at the predefined
interval.
After the Router processes and sends the ROM, it is able to send data
to the Radio. Since the Router has not received a Session Update
Message yet, the Router shall set its rate shaping to a default
value. The Router shall have the default rate shaping value defined
in its configuration.
The ROM shall have the following Mandatory TLV's:
1) None
The ROM has the following Optional TLV's:
1) Return Status TLV
The ROM with mandatory TLV's is depicted in Figure 5. A description
of the attributes of the Router Offer Message is contained in
Table 2.
Dubois, et al. Expires September 3, 2011 [Page 16]
Internet-Draft Radio-Router Control Protocol (R2CP) March 2011
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ver=0 | Rsvd | Code = 2 | Identifier Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Payload Length = 4 | TLV Type = 2 | TLV Length = 2|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Return Status |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: R2CP Router Offer Message
+------------+------------+--------+-------+------------------------+
| Attribute | Mandatory/ | Length | Value | Description |
| | Optional | (bits) | | |
+------------+------------+--------+-------+------------------------+
| Version | Mandatory | 4 | 0 | Version number |
| Reserved | Mandatory | 4 | 0 | Reserved for future |
| | | | | use |
| Code | Mandatory | 8 | 2 | Router Offer Message |
| Identifier | Mandatory | 16 | | R2CP packet identifier |
| R2CP Len | Mandatory | 16 | 4-257 | Length of packet |
| | | | | excluding header |
| TLV Code | Optional | 8 | 2 | Return Status TLV |
| TLV Len | Optional | 8 | 2-255 | Length of TLV Payload |
| TLV Value | Optional | 16 | | Return Status Code |
| | Optional | 0-2024 | | Return Status |
| | | | | Description |
+------------+------------+--------+-------+------------------------+
Table 2: R2CP Router Offer Message Values
4.2.3. Node Heartbeat Message (NHB)
The purpose of the Node Heartbeat Message is to maintain R2CP
association between the Radio and Router once it has been established
by a MIM/ROM exchange. The Heartbeat Interval is configured on the
Radio only and defaults to 5 seconds. The Routers learn the
Heartbeat Interval in the MIM that it receives from the Radio.
There may be instances when it is necessary to disable the Heartbeat
between the Radio and Router. Such examples could be to assist
troubleshooting or debugging a protocol problem and it is necessary
to eliminate the heartbeat message while continuing to exchange the
other R2CP messages.
After an R2CP adjacency is established, if the interval defined in
the MIM's Heartbeat Interval TLV is greater than zero, the Router
Dubois, et al. Expires September 3, 2011 [Page 17]
Internet-Draft Radio-Router Control Protocol (R2CP) March 2011
shall transmit the Node Heartbeat Message each time the interval
defined in the Heartbeat Interval TLV expires, with the heartbeat
interval starting when the ROM is transmitted. The Radio shall also
transmit the Node Heartbeat Message each time the interval defined in
the Heartbeat Interval TLV expires, with the heartbeat interval
starting when it receives the ROM from the Router. The heartbeat
messages are sent independently of any R2CP Session Level messages or
network traffic.
If the heartbeat interval is set to "0", the Radio and Router do not
send the Node Heartbeat Message but the rest of the R2CP protocol
messages continue to be used. Be aware that if the Heartbeat
Interval is set to 0, no automated recovery mechanism is provided
since there is no way to determine when the peer device has failed.
This setting should only be used for troubleshooting purposes.
The heartbeat interval is used to define how often the node sends the
Heartbeat Message. If a node receives a Heartbeat Message prior to
the heartbeat interval has expired, the receiving node shall accept
that heartbeat and renew/extend the heartbeat timer.
If the heartbeat interval configured for the current R2CP association
period is greater than zero, and if an R2CP node does not receive a
Node Heartbeat from its R2CP peer for three consecutive node
heartbeat interval periods, the R2CP node shall transmit a Node
Terminate Message containing a Return Status TLV with a Return Code
value of (14).
When the Node Terminate Message is sent, all established sessions are
cleared on the local device. The R2CP session will remain in the
down state until such time as a new R2CP session is established via
the normal MIM/ROM exchange process.
If the Radio terminates the R2CP association due to failing to
receive three consecutive Node Heartbeat Messages, the Radio shall
declare all sessions dead, clear R2CP association, restart sending
the MIM and should report the condition which caused the R2CP
association to be terminated.
If the Router terminates the R2CP association due to failing to
receive three consecutive Node Heartbeat messages, the Router shall
wait for a MIM and should report the condition which caused R2CP
association to be terminated.
The Heartbeat Interval cannot be changed for already established R2CP
radio/router sessions. If the Radio is re-configured with a
different Heartbeat Internal, the new Heartbeat Interval value is not
implemented until a new R2CP MIM/ROM exchange is completed.
Dubois, et al. Expires September 3, 2011 [Page 18]
Internet-Draft Radio-Router Control Protocol (R2CP) March 2011
The Node Heartbeat Message does not have any TLVs. If the Radio or
Router receives an invalid or unsolicited Node Heartbeat Message, the
receiver shall ignore the message and should report an invalid Node
Heartbeat Message was received.
The Node Heartbeat Message is depicted in Figure 6. A description of
the attributes of the Node Heartbeat Message is contained in Table 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ver=0 | Rsvd | Code = 3 | Identifier Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Payload Length = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: R2CP Node Heartbeat Message
+------------+------------+--------+-------+------------------------+
| Attribute | Mandatory/ | Length | Value | Description |
| | Optional | (bits) | | |
+------------+------------+--------+-------+------------------------+
| Version | Mandatory | 4 | 0 | Version number |
| Reserved | Mandatory | 4 | 0 | Reserved for future |
| | | | | use |
| Code | Mandatory | 8 | 3 | Node Heartbeat Message |
| Identifier | Mandatory | 16 | | R2CP packet identifier |
| R2CP Len | Mandatory | 16 | 0 | Length of packet |
| | | | | excluding header |
+------------+------------+--------+-------+------------------------+
Table 3: R2CP Node Heartbeat Message Values
4.2.4. Node Terminate Message (NTM)
The Node Terminate Message shall be sent from the Radio to Router or
from the Router to the Radio to terminate the R2CP neighbor
association in case of Node Heartbeat loss, loss of connectivity to
the radio network or administrative termination.
The source node of the Node Terminate Message should terminate the
R2CP association when it receives the Node Terminate ACK message, not
when it sends the Node Terminate Message.
Once the Node Terminate Message is received, the Router or Radio
shall close all sessions opened (via Session Initiate) for the
router/radio pair.
Dubois, et al. Expires September 3, 2011 [Page 19]
Internet-Draft Radio-Router Control Protocol (R2CP) March 2011
An invalid Node Terminate Message is defined as any malformed or
unsolicited Terminate Message received by the Router or Radio. If
the Radio receives an invalid Node Terminate Message, the Radio shall
ignore the message and should report an invalid Node Terminate
Message was received with the contents of the message. If the Router
receives an invalid Node Terminate Message, the Router shall ignore
the message and should report an invalid Node Terminate Message was
received with the contents of the message.
If no acknowledgement is received by the Sender after sending a Node
Terminate Message, the Node Terminate Message shall be retransmitted
up to N times at an interval M. The maximum total times the Node
Terminate Message is transmitted is N+1 times. The Node Terminate
retransmit quantity value of N shall be configurable by the user,
ranging from 1 to 5 with a default value of 3. The Node Terminate
retransmit interval value of M shall be configurable by the user,
ranging from 100 to 5,000 milliseconds with a default value of 1000
milliseconds.
If the Radio or Router does not receive the Node Terminate ACK
Message, the Radio or Router shall report the Node Terminate ACK
Message was not received with the contents of the Node Terminate
Message.
If the Radio or Router does not receive a Node Terminate ACK Message
to any of those messages, the Radio or Router shall terminate the
R2CP association.
The Radio or Router may optionally include the Return Status TLV in
with the Node Terminate Message to inform the peer node why request
to terminate the neighbor association (i.e. normal shutdown, failed
heartbeat, etc) has been made.
The Node Terminate Message is not required to have any TLV's. It may
include one Return Status TLV.
The Node Terminate Message with mandatory TLV's is depicted in
Figure 7. A description of the attributes of the Node Terminate
Message is contained in Table 4.
Dubois, et al. Expires September 3, 2011 [Page 20]
Internet-Draft Radio-Router Control Protocol (R2CP) March 2011
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ver=0 | Rsvd | Code = 4 | Identifier Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Payload Length = 4 | TLV Type = 2 | TLV Length = 2|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Return Status |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: R2CP Node Terminate Message
+------------+------------+--------+-------+------------------------+
| Attribute | Mandatory/ | Length | Value | Description |
| | Optional | (bits) | | |
+------------+------------+--------+-------+------------------------+
| Version | Mandatory | 4 | 0 | Version number |
| Reserved | Mandatory | 4 | 0 | Reserved for future |
| | | | | use |
| Code | Mandatory | 8 | 4 | Node Terminate Message |
| Identifier | Mandatory | 16 | | R2CP packet identifier |
| R2CP Len | Mandatory | 16 | 4-257 | Length of packet |
| | | | | excluding header |
| TLV Code | Optional | 8 | 2 | Return Status TLV |
| TLV Len | Optional | 8 | 2-255 | Length of TLV Payload |
| TLV Value | Optional | 16 | | Return Status Code |
| | Optional | 0-2024 | | Return Status |
| | | | | Description |
+------------+------------+--------+-------+------------------------+
Table 4: R2CP Node Terminate Message Values
4.2.5. Node Terminate ACK Message (NTA)
Upon receiving a valid Node Terminate Message, the Router or radio
shall terminate the association between the Radio and Router and send
a Node Terminate ACK Message.
The Identifier Number of the Node Terminate ACK Message shall be the
same value as the Identifier Number field in the Node Terminate
Message received.
If the Radio or Router receives a duplicate Node Terminate ACK
Message, the duplicate Node Terminate ACK Message can be ignored.
An invalid Node Terminate ACK Message is defined as any malformed or
unsolicited Node Terminate ACK Message received by either the radio
or router.
Dubois, et al. Expires September 3, 2011 [Page 21]
Internet-Draft Radio-Router Control Protocol (R2CP) March 2011
If the Radio or Router receives an invalid Node Terminate ACK
Message, the receiver should report an invalid Node Terminate ACK
Message was received.
The Node Terminate ACK Message shall have the following Mandatory
TLV's:
1) None
The Node Terminate ACK Message has the following Optional TLV's:
1) Return Status TLV
The Node Terminate ACK Message with mandatory TLV's is depicted in
Figure 8.
A description of the attributes of the Node Terminate ACK Message is
contained in Table 5.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ver=0 | Rsvd | Code = 5 | Identifier Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Payload Length = 4 | TLV Type = 2 | TLV Length = 2|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Return Status |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 8: R2CP Node Terminate ACK Message
+------------+------------+--------+-------+------------------------+
| Attribute | Mandatory/ | Length | Value | Description |
| | Optional | (bits) | | |
+------------+------------+--------+-------+------------------------+
| Version | Mandatory | 4 | 0 | Version number |
| Reserved | Mandatory | 4 | 0 | Reserved for future |
| | | | | use |
| Code | Mandatory | 8 | 5 | Node Term ACK Message |
| Identifier | Mandatory | 16 | | R2CP packet identifier |
| R2CP Len | Mandatory | 16 | 0 | Length of packet |
| | | | | excluding header |
| TLV Code | Optional | 8 | 2 | Return Status TLV |
| TLV Len | Optional | 8 | 2-255 | Length of TLV Payload |
| TLV Value | Optional | 16 | | Return Status Code |
| | Optional | 0-2024 | | Return Status |
| | | | | Description |
+------------+------------+--------+-------+------------------------+
Dubois, et al. Expires September 3, 2011 [Page 22]
Internet-Draft Radio-Router Control Protocol (R2CP) March 2011
Table 5: R2CP Node Terminate ACK Message Values
4.3. Session Level Messages
Session level R2CP messages are specific to an individual R2CP
session, or sessions in the case of multiple Session Updates
contained within a single Session Update Message. Individual R2CP
sessions are identified by unique R2CP session IDs.
4.3.1. Session Initiate Message (SIM)
As each Network Member (NM) radio logs in to the SATNET, each NM
learns, via the Radio Link Protocol, the MAC addresses of the
network's remote routers (i.e. routers attached to distant end NMs
and NC).
Each radio shall send a Session Initiate Message to its local Router
with the Remote MAC address. This is used by the router to associate
the R2CP session ID with the Ethernet MAC address and IP Address of
the remote destination: unicast, multicast or broadcast.
The Session Initiate Message shall set the Remote MAC to either the
Remote Routers MAC Address, the MAC Address associated with the
multicast group or the Ethernet broadcast MAC address.
The Radio can send Session Init messages in parallel (i.e. it does
not need to wait for an acknowledgement prior to sending the next
Session Init).
The Router will generate a unique session ID and embed the newly
generated session ID in a Session Initiate ACK Message in response to
Session Initiate request.
This Session ID is used both by the Router and Radio to track the
session for the newly discovered peer.
The value in the Session ID field shall be unique for each session
representing a remote destination between a router and Radio pair.
If the Radio does not receive an acknowledgement from the Router
after sending a Session Initiate message, the Radio shall retransmit
the Session Initiate message at an interval M.
The Session Initiate retransmit interval value of M shall be
configurable, ranging from 100 to 5,000 milliseconds with a default
value of 1000 milliseconds.
The Session Initiate message continues to be sent at interval M until
Dubois, et al. Expires September 3, 2011 [Page 23]
Internet-Draft Radio-Router Control Protocol (R2CP) March 2011
either the session is established or the distant radio neighbor is
lost.
If the Radio does not receive a Session Initiate ACK Message in
response to any of the Session Initiate messages sent for a
destination MAC address, it shall not initiate the session, but
instead attempt to initiate the session when it next receives an
over-the-air message containing the MAC address for the remote
destination for which a session is not yet established. The Radio
will not tear down any established sessions when this occurs.
An invalid Session Initiate message is defined as any malformed or
unsolicited Session Initiate Message received by the Router.
If the Router receives an invalid Session Initiate Message, the
Router shall ignore the message and should report an invalid Session
Initiate Message was received with the contents of the message.
In the case where a Radio receives data from the Router for a
destination that it does not have a neighbor for, the Radio shall
broadcast the packet to the network and send a Session Terminate
Message to the Router. After the remote and local radio nodes become
neighbors again, the Radio will send a Session Initiate Message.
The Session Initiate Message shall have the following Mandatory
TLV's:
1) Remote MAC Address TLV
The Session Initiate Message has the following Optional TLV's:
1) VLAN TLV
The Session Initiate Message with mandatory TLV's is depicted in
Figure 9.
A description of the attributes of the Session Initiate Message is
contained in Table 6.
Dubois, et al. Expires September 3, 2011 [Page 24]
Internet-Draft Radio-Router Control Protocol (R2CP) March 2011
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ver=0 | Rsvd | Code = 6 | Identifier Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Payload Length = 12 | TLV Type = 3 | TLV Length = 6|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Remote MAC Address (0:3) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Remote MAC Address (4:5) | TLV Type = 4 | TLV Length = 2|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| VLAN ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 9: R2CP Session Initiate Message
+------------+------------+--------+-------+------------------------+
| Attribute | Mandatory/ | Length | Value | Description |
| | Optional | (bits) | | |
+------------+------------+--------+-------+------------------------+
| Version | Mandatory | 4 | 0 | Version number |
| Reserved | Mandatory | 4 | 0 | Reserved for future |
| | | | | use |
| Code | Mandatory | 8 | 6 | Session Initiate |
| | | | | Message |
| Identifier | Mandatory | 16 | | R2CP packet identifier |
| R2CP Len | Mandatory | 16 | 12 | Length of packet |
| | | | | excluding header |
| TLV Code | Mandatory | 8 | 3 | Remote MAC Address TLV |
| TLV Len | Mandatory | 8 | 6 | Length of MAC Address |
| TLV Value | Mandatory | 48 | | MAC address |
| TLV Code | Optional | 8 | 4 | VLAN TLV |
| TLV Len | Optional | 8 | 2 | Length of VLAN field |
| TLV Value | Optional | 16 | | VLAN Identifier |
+------------+------------+--------+-------+------------------------+
Table 6: R2CP Session Initiate Message Values
4.3.2. Session Initiate ACK Message (SIA)
Upon receiving a valid Session Initiate Message, the Router shall
generate a unique 16-bit session ID and embed this session ID in a
Session Initiate ACK Message and then send the Session Initiate ACK
Message to its local radio.
There is a single Session ID associated with a remote MAC. If the
Router receives a Session Initiate Message for a Remote MAC it is
already aware of, it shall assign the Session ID already associated
Dubois, et al. Expires September 3, 2011 [Page 25]
Internet-Draft Radio-Router Control Protocol (R2CP) March 2011
with that Remote MAC and include that in the Session Initiate ACK
Message.
The Router shall generate a Session Initiate ACK Message for every
Session Initiate message it receives.
The Identifier Number shall be the same value as the Identifier
Number field in the Session Initiate Message received.
An invalid Session Initiate ACK Message is defined as any malformed
or unsolicited Session Initiate ACK Message received by the radio.
If the Radio receives an invalid Session Initiate ACK Message, the
Radio shall ignore the message and should report an invalid Session
Initiate ACK Message was received.
The Session Initiate ACK Message shall have the following Mandatory
TLV's:
1) Session ID TLV
The Session Initiate ACK Message has the following Optional TLV's:
1) VLAN TLV
2) Return Status TLV
The Session Initiate ACK Message with mandatory TLV's is depicted in
Figure 10.
A description of the attributes of the Session Initiate ACK Message
is contained in Table 7.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ver=0 | Rsvd | Code = 7 | Identifier Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Payload Length = 0x04 | TLV Type = 5 | TLV Length = 2|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Session ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 10: R2CP Session Initiate ACK Message
Dubois, et al. Expires September 3, 2011 [Page 26]
Internet-Draft Radio-Router Control Protocol (R2CP) March 2011
+------------+------------+--------+--------+-----------------------+
| Attribute | Mandatory/ | Length | Value | Description |
| | Optional | (bits) | | |
+------------+------------+--------+--------+-----------------------+
| Version | Mandatory | 4 | 0 | Version number |
| Reserved | Mandatory | 4 | 0 | Reserved for future |
| | | | | use |
| Code | Mandatory | 8 | 7 | Session Initiate ACK |
| | | | | Message |
| Identifier | Mandatory | 16 | | R2CP packet |
| | | | | identifier |
| R2CP Len | Mandatory | 16 | 12-265 | Length of packet |
| | | | | excluding header |
| TLV Code | Mandatory | 8 | 5 | Session ID TLV |
| TLV Len | Mandatory | 8 | 2 | Length of Session ID |
| TLV Value | Mandatory | 16 | | Session ID value |
| TLV Code | Optional | 8 | 4 | VLAN TLV |
| TLV Len | Optional | 8 | 2 | Length of VLAN field |
| TLV Value | Optional | 16 | | VLAN Identifier |
| TLV Code | Optional | 8 | 2 | Return Status TLV |
| TLV Len | Optional | 8 | 2-255 | Length of Return |
| | | | | Status Payload |
| TLV Value | Optional | 16 | | Return Status Code |
| | Optional | 0-2024 | | Return Status |
| | | | | Description |
+------------+------------+--------+--------+-----------------------+
Table 7: R2CP Session Initiate ACK Message Values
4.3.3. Session Update Message (SUM)
The Radio shall send a Session Update Message with the LQM
information to the Router immediately after the session is
established and whenever any of the LQM information values change.
The LQM information includes RLQ, Resource, Latency, Current Data
Rate, and Maximum Data Rate.
Typically the Radio sends a Session Update Message to the local
Router every epoch (400 milliseconds). In certain circumstances
(i.e.: the Radio can accommodate finer-grained flow control when
transporting delay-sensitive data, such as voice or video, by
allocating bursts in "subframes" which are units of time less than
400 milliseconds), the radio may send a Session Update Message more
often than every epoch. In other circumstances (when the network is
stable and the radio metrics are not changing), the Radio may send a
Session Update less often than every epoch.
The Router shall maintain the rate shaping values of the queue
Dubois, et al. Expires September 3, 2011 [Page 27]
Internet-Draft Radio-Router Control Protocol (R2CP) March 2011
controller based on the last update unless it receives a new update
from its Radio modem on the session.
The Radio can send multiple Session Update TLV's within the same
Session Update Message but the message should not be fragmented.
When multiple Session TLVs are included in the same Session Update
Message, the sequence of the TLVs is critical. Every set of TLVs
associated with a specific session shall immediately follow the
Session TLV. When a second session is then added, all TLVs following
the second Session TLV are associated with the second session. The
order of the TLVs associated with the Session is not specific since
each TLV has a unique TLV code. An example is contained in
Figure 11.
+-----------------------+
| IP Header |
| UDP Header |
| R2CP Header |
+-----------------------+
| Session TLV id:1 |\
| Latency TLV | \
| Current Data Rate TLV | \ Session 1
| Maximum Data Rate TLV | /
| RLQ TLV | /
|_ _ _Resource TLV _ _ _|/
| Session TLV id:2 |\
| Latency TLV | \
| Current Data Rate TLV | \ Session 2
| Maximum Data Rate TLV | /
| RLQ TLV | /
|_ _ _Resource TLV _ _ _|/
| Session TLV id:N |\
: : : : Session N
+-----------------------+
Figure 11: Bundled Session Message
If the radio link metrics do not change, the Radio shall NOT need to
send a new Session Update Message to the Router. The Router will
continue to use the previous metrics.
An invalid Session Update Message is defined as any malformed or
unsolicited Session Update Message received by the Router.
If the Router receives an invalid Session Update Message the Router
shall attempt to process the valid portions of the message and should
report an invalid Session Update Message was received identifying the
Dubois, et al. Expires September 3, 2011 [Page 28]
Internet-Draft Radio-Router Control Protocol (R2CP) March 2011
invalid portions of the message.
The Session Update Message shall have the following Mandatory TLV's,
one set for each session being updated:
1. Session ID TLV
2. Latency Metric TLV
3. Current Data Rate Metric TLV
4. Maximum Data Rate Metric TLV
5. RLQ Metric TLV
6. Resource Metric TLV
The Session Update Message has no Optional TLV's.
The Session Update Message with mandatory TLV's is depicted in
Figure 12. A description of the attributes of the Session Update
Message is contained in Table 8.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ver=0 | Rsvd | Code = 8 | Identifier Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Payload Length | TLV Type = 5 | TLV Length = 2|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Session ID | TLV Type = 8 | TLV Length = 2|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Latency | TLV Type = 9 | TLV Length = 4|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Current Data Rate (kbps) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TLV Type = 10 | TLV Length = 4| Maximum Data Rate (kbps) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Maximum Data Rate (con't) | TLV Type = 6 | TLV Length = 1|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RLQ | TLV Type = 7 | TLV Length = 1| Resources |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TLV Type = 5 ...
+-+-+-+-+-+-+-+-...
Figure 12: R2CP Session Update Message
Dubois, et al. Expires September 3, 2011 [Page 29]
Internet-Draft Radio-Router Control Protocol (R2CP) March 2011
+------------+------------+--------+-------+------------------------+
| Attribute | Mandatory/ | Length | Value | Description |
| | Optional | (bits) | | |
+------------+------------+--------+-------+------------------------+
| Version | Mandatory | 4 | 0 | Version number |
| Reserved | Mandatory | 4 | 0 | Reserved for future |
| | | | | use |
| Code | Mandatory | 8 | 8 | Session Update Message |
| Identifier | Mandatory | 16 | | R2CP packet identifier |
| R2CP Len | Mandatory | 16 | >=26 | Length of packet |
| | | | | excluding header |
| TLV Code | Mandatory | 8 | 5 | Session ID TLV |
| TLV Len | Mandatory | 8 | 2 | Length of Session ID |
| TLV Value | Mandatory | 16 | | Session ID value |
| TLV Code | Mandatory | 8 | 8 | Latency TLV |
| TLV Len | Mandatory | 8 | 2 | Length of Latency |
| | | | | field |
| TLV Value | Mandatory | 16 | | Latency, in |
| | | | | milliseconds |
| TLV Code | Mandatory | 8 | 9 | Current Data Rate TLV |
| TLV Len | Mandatory | 8 | 4 | Length of Current Data |
| | | | | Rate Value |
| TLV Value | Mandatory | 32 | | Current Data Rate in |
| | | | | kbps |
| TLV Code | Mandatory | 8 | 10 | Maximum Data Rate TLV |
| TLV Len | Mandatory | 8 | 4 | Length of Maximum Data |
| | | | | Rate Value |
| TLV Value | Mandatory | 32 | | Maximum Data Rate in |
| | | | | kbps |
| TLV Code | Mandatory | 8 | 8 | RLQ TLV |
| TLV Len | Mandatory | 8 | 1 | Length of RLQ field |
| TLV Value | Mandatory | 8 | 0-255 | RLQ Value |
| TLV Code | Mandatory | 8 | 8 | Resource TLV |
| TLV Len | Mandatory | 8 | 1 | Length of Resource |
| | | | | field |
| TLV Value | Mandatory | 8 | 0-100 | Resource Value |
+------------+------------+--------+-------+------------------------+
Table 8: R2CP Session Update Message Values
The values in the following fields shall be used for route metric
calculation. The names and purpose of these fields are the same as
those in the PPPoE PADQ Discovery message Metrics TLV as described in
[RFC5578] for the Radio, but the values in these fields are specific
to the LAN-over-Radio network. See Section 5 for an example on how
the router makes use of these values to assign link costs to OSPF.
Dubois, et al. Expires September 3, 2011 [Page 30]
Internet-Draft Radio-Router Control Protocol (R2CP) March 2011
Maximum Data Rate
The Maximum Outbound Data Rate reported in an R2CP Session Update
Message for a unicast link-layer address shall be determined and
provided by the Radio.
The Maximum Outbound Data Rate reported in an R2CP Session Update
Message for a multicast or broadcast link-layer address shall be
zero.
The Maximum Data Rate shall be an unsigned 32-bit field that
contains the maximum theoretical data rate in kbps that the link
is capable of providing.
Current Data Rate
The Current Data Rate is the Radio's estimate of the actual link
throughput and is calculated as a smoothed average of the link's
recent throughput rates. Smoothing is described in Section 4.5.
Note that Current Data Rate applies to the aggregate of all data
flows to the remote node or multicast group, independent of the
flows' priorities, delay sensitivity or other QoS factors.
The value in the Current Data Rate for unicast link-layer
addresses shall be less than or equal to the value in the Maximum
Data Rate field.
The Current Data Rate shall be an unsigned 32-bit field that
contains the current smoothed average throughput in kbps that the
link is actually providing.
Latency
The Latency shall be a 16-bit field that is the message queuing
delay plus a default RF transmission delay.
The Latency value shall be represented in milliseconds.
Resources
The Resources field is used to indicate the percentage of system
resources (i.e. battery power) that is available.
The Resources field shall be an 8-bit field in the range from 0
to 100. If system resources cannot be calculated, a default
value of 100 shall be reported.
Dubois, et al. Expires September 3, 2011 [Page 31]
Internet-Draft Radio-Router Control Protocol (R2CP) March 2011
Relative Link Quality (RLQ)
The RLQ is used to indicate the quality of the radio link. It is
an unsigned 8-bit value.
4.3.4. Session Terminate Message (STM)
The Session Terminate Message is sent from the Radio to Router or
from the Router to the Radio to terminate the session in case of lost
RF connection or administrative Session Terminate.
Once this message is received, the Router or Radio shall remove the
session associated with the destination MAC address.
If an acknowledgement is not received by the Sender after sending a
Session Terminate Message, the Session Terminate Message shall be
retransmitted up to total N times at an interval M. The maximum total
times the Session Terminate message is transmitted is N+1 times.
The Session Terminate retransmit quantity value of N shall be
configurable, ranging from 1 to 5 with a default value of 3.
The Session Terminate retransmit interval value of M shall be
configurable, ranging from 100 to 5,000 milliseconds with a default
value of 1000 milliseconds.
If the Router or Radio does not receive the Session Terminate ACK
Message in response, it should report the Session Terminate ACK
Message was not received with the contents of the Session Terminate
Message.
If the Radio or Router does not receive a Session Terminate ACK
Message to any of those messages, it shall terminate the session.
When the local node has sent multiple Session Terminate messages due
to the retransmit timer and then receives a Session Terminate ACK
Message, the local node shall terminate the session and then ignore
any more Session Terminate ACK Messages it receives related to that
session.
When the local node is in the state waiting for Session Terminate ACK
Message, and it receives a Session Terminate Message, the local node
shall send Session Terminate ACK Message for the received Session
Terminate Message, and clear the session without waiting for a
Session Terminate ACK Message to its Session Terminate Message.
An invalid Session Terminate Message is defined as any malformed or
unsolicited Terminate Message received by the Router or the radio.
Dubois, et al. Expires September 3, 2011 [Page 32]
Internet-Draft Radio-Router Control Protocol (R2CP) March 2011
If the Radio or Router receives an invalid Session Terminate Message,
the receiver shall ignore the message and should report an invalid
Session Terminate Message was received.
If the Router or Radio receives a Session Terminate Message to a
session that is not established, the Router or radio should send an
ACK and do nothing else. Since the session has not been established,
there is nothing to terminate and in effect, the termination has been
accomplished.
The Session Terminate Message shall have the following Mandatory
TLV's:
1) Session ID TLV
The Session Terminate Message has the following Optional TLV's:
1) VLAN TLV
2) Return Status TLV
The Session Terminate Message with mandatory TLV's is depicted in
Figure 13.
A description of the attributes of the Session Terminate Message is
contained in Table 9.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ver=0 | Rsvd | Code = 9 | Identifier Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Payload Length | TLV Type = 5 | TLV Length = 2|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Session ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 13: R2CP Session Terminate Message
Dubois, et al. Expires September 3, 2011 [Page 33]
Internet-Draft Radio-Router Control Protocol (R2CP) March 2011
+------------+------------+--------+-------+------------------------+
| Attribute | Mandatory/ | Length | Value | Description |
| | Optional | (bits) | | |
+------------+------------+--------+-------+------------------------+
| Version | Mandatory | 4 | 0 | Version number |
| Reserved | Mandatory | 4 | 0 | Reserved for future |
| | | | | use |
| Code | Mandatory | 8 | 6 | Session Initiate |
| | | | | Message |
| Identifier | Mandatory | 16 | | R2CP packet identifier |
| R2CP Len | Mandatory | 16 | 12 | Length of packet |
| | | | | excluding header |
| TLV Code | Mandatory | 8 | 5 | Session ID TLV |
| TLV Len | Mandatory | 8 | 2 | Length of Session ID |
| TLV Value | Mandatory | 16 | | Session ID value |
| TLV Code | Optional | 8 | 4 | VLAN TLV |
| TLV Len | Optional | 8 | 2 | Length of VLAN field |
| TLV Value | Optional | 16 | | VLAN Identifier |
| TLV Code | Optional | 8 | 2 | Return Status TLV |
| TLV Len | Optional | 8 | 2-255 | Length of Return |
| | | | | Status |
| TLV Value | Optional | 16 | | Return Status Code |
| | Optional | 0-2024 | | Return Status |
| | | | | Description |
+------------+------------+--------+-------+------------------------+
Table 9: R2CP Session Terminate Message Values
4.3.5. Session Terminate ACK Message (STA)
Upon receiving a valid Session Terminate Message, the Router or Radio
shall respond with a Session Terminate ACK Message.
The Identifier Number and Session ID fields shall be the same values
as the Identifier Number and Session ID fields in the Session
Terminate Message received.
An invalid Session Terminate ACK Message is defined as any malformed
or unsolicited ACK Message received by either the Radio or Router.
If the Radio or Router receives an invalid Session Terminate ACK
Message, the receiver shall ignore the message and should report an
invalid Session Terminate ACK Message was received.
If the Radio or Router receives a duplicate Session Terminate ACK
Message, the duplicate Session Terminate ACK Message can be ignored.
The Session Terminate ACK Message shall have the following Mandatory
Dubois, et al. Expires September 3, 2011 [Page 34]
Internet-Draft Radio-Router Control Protocol (R2CP) March 2011
TLV's
1) Session ID TLV
The Session Terminate ACK Message has the following Optional TLV's:
1) Return Status TLV
2) VLAN TLV
The Session Terminate ACK Message with mandatory TLV's is depicted in
Figure 14.
A description of the attributes of the Session Terminate ACK Message
is contained in Table 10.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ver=0 | Rsvd | Code = 10 | Identifier Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Payload Length | TLV Type = 5 | TLV Length = 2|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Session ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 14: R2CP Session Terminate ACK Message
Dubois, et al. Expires September 3, 2011 [Page 35]
Internet-Draft Radio-Router Control Protocol (R2CP) March 2011
+------------+------------+--------+--------+-----------------------+
| Attribute | Mandatory/ | Length | Value | Description |
| | Optional | (bits) | | |
+------------+------------+--------+--------+-----------------------+
| Version | Mandatory | 4 | 0 | Version number |
| Reserved | Mandatory | 4 | 0 | Reserved for future |
| | | | | use |
| Code | Mandatory | 8 | 10 | Session Terminate ACK |
| | | | | Message |
| Identifier | Mandatory | 16 | | R2CP packet |
| | | | | identifier |
| R2CP Len | Mandatory | 16 | 12-265 | Length of packet |
| | | | | excluding header |
| TLV Code | Mandatory | 8 | 5 | Session ID TLV |
| TLV Len | Mandatory | 8 | 2 | Length of Session ID |
| TLV Value | Mandatory | 16 | | Session ID value |
| TLV Code | Optional | 8 | 4 | VLAN TLV |
| TLV Len | Optional | 8 | 2 | Length of VLAN field |
| TLV Value | Optional | 16 | | VLAN Identifier |
| TLV Code | Optional | 8 | 2 | Return Status TLV |
| TLV Len | Optional | 8 | 2-255 | Length of Return |
| | | | | Status Payload |
| TLV Value | Optional | 16 | | Return Status Code |
| | Optional | 0-2024 | | Return Status |
| | | | | Description |
+------------+------------+--------+--------+-----------------------+
Table 10: R2CP Session Terminate ACK Message Values
4.4. R2CP Type-Length-Value (TLV) Definitions
R2CP shall use Type-Length-Value (TLV) fields to construct the
various R2CP message types. Each R2CP message type will consist of a
list of required TLV's and optional TLV's. TLV fields are not
aligned to either full or half-word boundaries and are treated as
character arrays, a given TLV may appear multiple times in a single
packet and in any order.
If the Router or Radio receives an R2CP message containing a TLV
which is specifically disallowed in a message, the message shall be
declared malformed and ignored.
If the Router or Radio receives an R2CP message containing a TLV
which is unknown during parsing, the unknown TLV shall be ignored,
stepped over, and parsing continued. Assuming no errors are
encountered, the message is processed. Unknown TLVs represent
optional or new features not yet supported in a given implementation.
Dubois, et al. Expires September 3, 2011 [Page 36]
Internet-Draft Radio-Router Control Protocol (R2CP) March 2011
Each TLV shall consist of three fields.
o The Type Field shall be an 8-bit field indicating the type of
field this part of the message represents. TLV Type Code 0x00 is
reserved and shall not be used. In the event TLV code 0x00 is
encountered, the message shall be declared malformed and ignored.
o The Length Field shall be an 8-bit field which specifies the
length, in octets, of the TLV payload or value. It does not
include either the Type or Length fields.
o The Value Field shall be a variably sized field, as defined by the
TLV Length Field, containing the payload of TLV.
If a message or TLV is received that represents a disabled feature,
the receiver shall ignore the message or TLV, and generate a single
log entry per system uptime indicating a disabled TLV was received
and include the contents of the disabled TLV.
Table 13 lists the TLV Codes used in the R2CP protocol
4.4.1. Node Heartbeat Interval TLV
The Node Heartbeat TLV is used to identify the Heartbeat interval
that will be used between the radio and router. Both devices need to
agree upon the interval.
The Node Heartbeat Interval TLV Code shall be 0x01.
The Node Heartbeat Interval shall be a 16-bit field with values that
range from 0 to 60 seconds inclusive with a default value of 5
seconds.
The Router sets its Heartbeat Interval to the value received from the
Radio.
When the Heartbeat Interval value is 0, Heartbeats are not
transmitted by either Radio or Router.
A sample Node Heartbeat Interval TLV is contained in Figure 15.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TLV Code = 1 | Length = 2 | Heartbeat Interval (secs) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 15: R2CP Node Heartbeat Interval TLV
Dubois, et al. Expires September 3, 2011 [Page 37]
Internet-Draft Radio-Router Control Protocol (R2CP) March 2011
4.4.2. Return Status TLV
The Return Status TLV is used to provide more detail on the message.
It is an optional TLV that may be added to the ROM, Node Terminate,
Session Terminate, and Session Terminate ACK messages.
The Return Status TLV Code shall be 0x02.
The Return Status Value Field shall be a 16 bit field with a zero
value indicating success and an all non-zero value indicating
failure. The Return Status of non-0 shall indicate an unsuccessful
message. The absence of an optional Return Status TLV shall serve as
an implicit indication of success.
The Return Status of 1 shall indicate a generic failure and the
Optional Return Status Text field is used to further explain the
problem.
The Return Status Text field is an Optional free form text field used
to describe the error code. The string should be used to provide
meaningful information to the user on the receiving side. It should
not be used to simply repeat the Return Status Code value.
The Return Status Text field shall not be NULL terminated. The
Length field is sufficient to indicate the length of the display
string.
See Table 14 for more detailed explanation of the Return Code and
Return Status TLV fields.
A sample Return Status TLV is contained in Figure 16.
The standard Return Codes are defined in Table 14.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TLV Code = 2 | Length | Return Status Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Return Status Text (optional, variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 16: R2CP Return Status TLV
The proposed set of values for the Return Status codes defined for
the Radio-Router Control Protocol (R2CP) between the local Radio and
Router can be found in Table 14. The "Status" column in this table
has the value "error", indicating that the R2CP node sending the
Dubois, et al. Expires September 3, 2011 [Page 38]
Internet-Draft Radio-Router Control Protocol (R2CP) March 2011
message did not perform the action requested by its peer, or "info",
indicating that the R2CP node performs the action in the previously
received request message to which this message containing the Return
Status TLV is responding.
4.4.3. Remote MAC Address TLV
The Remote MAC Address TLV is used for the radio to inform the router
of the MAC address of the distant router or the multicast group MAC
address associated with a particular session. The Radio initially
provides this information in the Session Initiate message.
The Remote MAC Address TLV Code shall be 0x03.
The Remote MAC Address Value Field shall be a 48 bit field.
A sample Remote MAC Address TLV is contained in Figure 17.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TLV Code = 3 | Length = 6 | Remote MAC Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Remote MAC Address (con't) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 17: Remote MAC Address TLV
4.4.4. Reserved (VLAN) TLV
This TLV is reserved for future use.
4.4.5. Session ID TLV
The Session ID TLV is used to uniquely identify an R2CP session.
The Router shall calculate the Session ID based on the Ethernet MAC
address associated with the R2CP destination.
The Session ID is included in each message to indicate which session
the message content is associated with.
The Session ID TLV Code shall be 0x05.
The Session ID Value Field shall be a 16 bit field.
A sample Session ID TLV is contained in Figure 18.
Dubois, et al. Expires September 3, 2011 [Page 39]
Internet-Draft Radio-Router Control Protocol (R2CP) March 2011
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TLV Code = 5 | Length = 2 | Session ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 18: R2CP Session ID TLV
4.4.6. RLQ Metric TLV
The RLQ Metric TLV is used to identify the RLQ metric for the
session. It is included in the Session Update message. See
Section 4.3.3 and Section 5 for a discussion about the meaning of
RLQ.
The RLQ Metric TLV Code shall be 0x06.
The RLQ Metric Value Field shall be a 8 bit field.
Valid RLQ values range from 0-100, inclusive with 100 representing
the best conditions and 0 indicating the quality of the link is not
useable.
A sample RLQ Metric TLV is contained in Figure 19.
0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TLV Code = 6 | Length = 1 | RLQ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 19: R2CP RLQ Metric TLV
4.4.7. Resource Metric TLV
The Resource Metric TLV is used to identify the Resource metric for
the session. It is included in the Session Update message. See
Section 4.3.3 and Section 5 for a discussion about the meaning of
Resource.
The Resource Metric TLV Code shall be 0x07.
The Resource Metric Value Field shall be a 8 bit field.
Valid Resource values range from 0-100, inclusive with 100
representing the best conditions and 0 indicating there are no
resources
Dubois, et al. Expires September 3, 2011 [Page 40]
Internet-Draft Radio-Router Control Protocol (R2CP) March 2011
A sample Resource Metric TLV is contained in Figure 20.
0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TLV Code = 7 | Length = 1 | Resource |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 20: R2CP Resource Metric TLV
4.4.8. Latency Metric TLV
The Latency Metric TLV is used to identify the Latency metric for the
session. It is included in the Session Update message. See
Section 4.3.3 and Section 5 for a discussion about the meaning of
Latency.
The Latency Metric TLV Code shall be 0x08.
The Latency Metric Value Field shall be a 16 bit field.
Latency is a 16-bit unsigned value representing milliseconds.
A sample Latency Metric TLV is contained in Figure 21.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TLV Code = 8 | Length = 2 | Latency (milliseconds) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 21: R2CP Latency Metric TLV
4.4.9. Current Data Rate Metric TLV
The Current Data Rate Metric TLV is used to identify the Current Data
Rate metric for the session. It is included in the Session Update
message. See Section 4.3.3 and Section 5 for a discussion about the
meaning of Current Data Rate.
The Current Data Rate Metric TLV Code shall be 0x09.
The Current Data Rate Metric Value Field shall be a 32 bit field.
CDR is a 16-bit unsigned value representing kilobits per second.
CDR must be less than or equal to MDR for unicast sessions.
Dubois, et al. Expires September 3, 2011 [Page 41]
Internet-Draft Radio-Router Control Protocol (R2CP) March 2011
A sample Current Data Rate Metric TLV is contained in Figure 22.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TLV Code = 9 | Length = 4 | Current Data Rate |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Current Data Rate (cont'd) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 22: R2CP Current Data Rate TLV
4.4.10. Maximum Data Rate Metric TLV
The Maximum Data Rate Metric TLV is used to identify the Maximum Data
Rate metric for the session. It is included in the Session Update
message. See Section 4.3.3 and Section 5 for a discussion about the
meaning of Maximum Data Rate.
The Maximum Data Rate Metric TLV Code shall be 0x0a.
The Maximum Data Rate Metric Value Field shall be a 32 bit field.
MDR is a 16-bit unsigned value representing kilobits per second.
A sample Maximum Data Rate Metric TLV is contained in Figure 23.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TLV Code = 10 | Length = 4 | Maximum Data Rate |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Maximum Data Rate (cont'd) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 23: R2CP Maximum Data Rate TLV
4.5. Data Smoothing
Smoothing should be performed both at the Router and the Radio. The
Radio should calculate a smoothed average of both the Maximum Data
Rate and the Current Data Rate prior to transferring this data to the
Router. A possible method to smooth the data could be using a 10
second sliding window that ignores the top 3 and low 3 sample points
of the current window (25 total samples) and averages the remaining
19 samples with the average of the previous 10 second sample.
The Router shall use this smoothed data to set the queue rate shaping
Dubois, et al. Expires September 3, 2011 [Page 42]
Internet-Draft Radio-Router Control Protocol (R2CP) March 2011
value.
The Router shall calculate a new OSPF Link cost based on this
smoothed data, but it will not publish the new link cost to neighbor
nodes until either a time limit has been reached (e.g. 1 minute) or
the value has changed by a certain percentage (e.g.+/- 10%). This
will reduce the network overhead by only reporting link changes when
they will have a significant impact on routing.
The Router shall provide a configurable value for the smoothing
percentage from 0 to 100 with a default of 10.
A Radio shall overload the current allocated session bandwidth in
order to encourage the Router to send more data than the Radio can
support so that it always attempts to increase the amount of data it
will send over the airwaves. Otherwise the Radio will never know
that the Router has more data to transmit and the Router will not
know that the Radio has a greater amount of transmit bandwidth
available to it.
The Radio shall employ an algorithm to control its overloading rate.
The Overload Rate shall be a configurable radio parameter from 0 to
100 with a default of 10.
The Radio will inform the Router the data rate it wants sent to the
radio. The radio will oversubscribe the link by requesting from the
Router more data than the link can provide. The Router will send to
the radio the amount the radio requested.
5. OSPF Link Cost Assignments
The Router shall calculate the link cost by using the following
formula. The Router routes traffic based on the OSPF "Shortest Path
First" algorithm as described in [RFC2328] and [RFC5340] that uses
the link cost. As stated above, the Latency is in milliseconds and
data rate in kilobits per second. Refer to Figure 24 and Table 11
for the method to calculate the OSPF cost from the radio link
metrics.
Dubois, et al. Expires September 3, 2011 [Page 43]
Internet-Draft Radio-Router Control Protocol (R2CP) March 2011
BW Weight
OSPF Cost = Cost Bias + Data Rate Factor * ( ------------ )
Max Weight
Resource Weight
+ Resource Factor * ( ----------------- )
Max Weight
Latency Weight
+ Latency Factor * ( ---------------- )
Max Weight
RLQ Weight
+ RLQ Factor * ( ------------ )
Max Weight
8
(10 / MDR )
Cost Bias = --------------
1000
CDR
65536 * ( ( 1 - ----- ) * Max Weight )
Data Rate MDR
Factor = -----------------------------------------
Max Weight
CDR = Current Data Rate Metric * (DR Weight / Max Weight)
MDR = Maximum Data Rate Metric * (DR Weight / Max Weight)
3
( 100 - Resource Metric ) * 65536
Resource = -----------------------------------
Factor 1000000
Latency Factor = Latency Metric as reported by Radio
( 100 - RLQ Metric ) * 65536
RLQ Factor = ------------------------------
Max Weight
Figure 24: OSPF Algorithm Definition
Dubois, et al. Expires September 3, 2011 [Page 44]
Internet-Draft Radio-Router Control Protocol (R2CP) March 2011
+--------------------+---------------+--------------------+
| Resource Component | Default Value | Configurable Range |
+--------------------+---------------+--------------------+
| BW Weight | 100 | 0-100 |
| Resource Weight | 100 | 0-100 |
| Latency Weight | 100 | 0-100 |
| RLQ Weight | 100 | 0-100 |
| DR Weight | 100 | 0-100 |
| Max Weight | 100 | N/A |
+--------------------+---------------+--------------------+
Table 11: User Defined Values
6. Acknowledgements
The authors would like to thank these additional contributors: Raniel
Babala, Thomas Christofili, Alan Chung, Mark Cusano, Dennis J.
Daniels, Mark Finney, Lakshman Garikapaty, Ryan Hitch, Sheng Huang,
John Kantonides, Padma Krishnaswamy, Steve Mally, Manuel Meade, Paul
Morhy, Eric Peterson, Alan Plum, Stan Ratliff, David Ruffen, Richard
Rockweiler, Darryl Satterwhite, Frank Solensky, Sivananda
Subramaniam, Chris Wilson
7. IANA Considerations
7.1. R2CP Port Number
The router that acts as an R2CP server listen on a registered UDP
Port Number for messages from its client radios. The title of this
port is "r2cps" (R2CP Server). The value of this UDP port is TBD1
[the value 28762 is suggested as it is used in prototype
implementations].
7.2. R2CP Code Definitions
This document defines a set of 8-bit Code values for which IANA is to
create and maintain a new sub-registry entitled "R2CP Code values".
Initial values for the R2CP Code values registry are given below;
future assignments are to be made through Expert Review [RFC5226].
Assignments consist of an R2CP Code name and its associated value.
Dubois, et al. Expires September 3, 2011 [Page 45]
Internet-Draft Radio-Router Control Protocol (R2CP) March 2011
+--------+-----------------------+---------------+
| Value | R2CP Code name | Defined in |
+--------+-----------------------+---------------+
| 0 | Reserved | |
| 1 | Modem Initiate | Section 4.2.1 |
| 2 | Router Offer | Section 4.2.2 |
| 3 | Node Heartbeat | Section 4.2.3 |
| 4 | Node Terminate | Section 4.2.4 |
| 5 | Node Terminate ACK | Section 4.2.5 |
| 6 | Session Initiate | Section 4.3.1 |
| 7 | Session Initiate ACK | Section 4.3.2 |
| 8 | Session Update | Section 4.3.3 |
| 9 | Session Terminate | Section 4.3.4 |
| 10 | Session Terminate ACK | Section 4.3.5 |
| 11-254 | Unassigned | |
| 255 | Reserved | |
+--------+-----------------------+---------------+
Table 12: R2CP Message Codes
7.3. R2CP TLV Type Definitions
This document defines a set of 8-bit Type Identifiers for which IANA
is to create and maintain a new sub-registry entitled "R2CP Type
values". Initial values for the R2CP Type values registry are given
below; future assignments are to be made through Expert Review
[RFC5226]. Assignments consist of an R2CP Type name and its
associated value.a
+--------+--------------------------------+----------------+
| Value | R2CP Type name | Defined in |
+--------+--------------------------------+----------------+
| 0 | Reserved | |
| 1 | Node Heartbeat Interval | Section 4.4.1 |
| 2 | Return Status | Section 4.4.2 |
| 3 | Remote MAC Address | Section 4.4.3 |
| 4 | VLAN Identifier | Section 4.4.4 |
| 5 | Session Identifier | Section 4.4.5 |
| 6 | RLQ Metric | Section 4.4.6 |
| 7 | Resource Metric | Section 4.4.7 |
| 8 | Latency Metric | Section 4.4.8 |
| 9 | Current Data Rate Metric | Section 4.4.9 |
| 10 | Maximum Data Rate Metric | Section 4.4.10 |
| 11-253 | Unassigned | |
| 254 | Reserved (radio or router use) | |
| 255 | Reserved | |
+--------+--------------------------------+----------------+
Dubois, et al. Expires September 3, 2011 [Page 46]
Internet-Draft Radio-Router Control Protocol (R2CP) March 2011
Table 13: R2CP TLV types
7.4. R2CP Error Code Definitions
This document defines a set of 8-bit Error Codes for which IANA is to
create and maintain a new sub-registry entitled "R2CP Error Code
values". Initial values for the R2CP Error Code values registry are
given below; future assignments are to be made through Expert Review
[RFC5226]. Assignments consist of an R2CP Error type name and its
associated value.
+--------+---------------------------------+--------+---------------+
| Value | R2CP Error Code name | Status | Defined in |
+--------+---------------------------------+--------+---------------+
| 0 | Reserved | error | |
| 1 | No Return Code Defined | error | |
| 2 | Invalid VLAN ID | error | |
| 3 | Undefined Message Type | error | Section 4.2 |
| 4 | Invalid Message type | error | Section 4.2 |
| 5 | Unassigned | | |
| 6 | Invalid Control Flag Set | error | Section 4.2 |
| 7 | Invalid Payload Length | error | Section 4.2 |
| 8 | Omitted Mandatory TLV | error | Section 4.2 |
| 9 | Disallowed TLVs | error | Section 4.2 |
| 10 | Invalid TLV Length | error | Section 4.2 |
| 11 | Invalid TLV Value | error | Section 4.2 |
| 12 | Data VLAN ID not configured | error | |
| 13 | Data VLAN ID previously | info | |
| | configured | | |
| 14 | Node Heartbeat Lost | info | Section 4.2.3 |
| 15 | Network Unreachable | info | |
| 16 | Command Terminate | info | |
| 17-254 | Unassigned | | |
| 255 | Reserved | | |
+--------+---------------------------------+--------+---------------+
Table 14: R2CP Error Codes
8. Security Considerations
Security considerations are not addressed at this time.
9. Open Source Implementation
An open source (MIT License) R2CP implementation is available at
<http://sourceforge.net/projects/r2cptools>.
Dubois, et al. Expires September 3, 2011 [Page 47]
Internet-Draft Radio-Router Control Protocol (R2CP) March 2011
An open source (GPLv2) wireshark decoder is available at
<http://sourceforge.net/projects/r2cptools>.
10. References
10.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.
[RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF
for IPv6", RFC 5340, July 2008.
10.2. Informative References
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008.
[RFC5578] Berry, B., Ratliff, S., Paradise, E., Kaiser, T., and M.
Adams, "PPP over Ethernet (PPPoE) Extensions for Credit
Flow and Link Metrics", RFC 5578, February 2010.
Appendix A. Terms and Definitions
BW Bandwidth
IETF Internet Engineering Task Force
MAC Media Access Control
Mesh the virtual communication backbone formed by the nodes and
comm links over time-Data can be moved from Node 1 to every
other node over the available network mesh
OSPF Open Shortest Path First (a link state interior gateway
routing protocol standard), described in [RFC2328] and
[RFC5340].
QoS Quality of Service
Dubois, et al. Expires September 3, 2011 [Page 48]
Internet-Draft Radio-Router Control Protocol (R2CP) March 2011
RF Radio Frequency
RLP Radio Link Protocol
SATCOM Satellite Communication
TS Transmission Subsystem
VLAN Virtual Local Area Network
Authors' Addresses
Dave Dubois (editor)
General Dynamics C4 Systems
400 John Quincy Adams Rd.
Taunton, MA 02780
US
Phone: +1 508 880 2249
Email: Dave.Dubois@gdc4s.com
Ashwin Kovummal
Juniper Networks
10 Technology Park Dr.
Westford, MA 01886
US
Phone: +1 978 589 0864
Email: akovummal@juniper.net
Brian Petry
L-3 Communications
3033 Science Park Road
San Diego, CA 92121
US
Phone: +1 858 552 9650
Email: Brian.Petry@l-3com.com
Dubois, et al. Expires September 3, 2011 [Page 49]
Internet-Draft Radio-Router Control Protocol (R2CP) March 2011
Bo Berry
Cisco Systems
170 West Tasman Drive
San Jose, CA 95134
US
Phone: +1 919 392 2926
Email: boberry@cisco.com
Dubois, et al. Expires September 3, 2011 [Page 50]
