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 . 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 . 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]