Modem Link Properties Advertisement Protocol
draft-ivancic-mobopts-modemlpa-00

Abstract

Nework devices and applications are increasingly connected to a variety of smart modems whose incoming and outgoing link rates can be varied over time to suit the channel characteristics. Such rate changes can result from use of adaptive coding and modulation. The link rate and conditions offered by the modem to connected devices therefore vary. In order for connected devices and applications to get the most out of the modem's link capacity, it is necessary for the applications and connected devices to condition traffic. Thus, they need some knowledge of the modem's link conditions. This document describes one simple method for a modem to advertise link rate and other characteristics, via UDP messages, and discusses alternative approaches to communicating this information. While the mechanism in this document is described in the context of a modem, it can also be broadly applied to other scenarios such as cryptographic devices.

Status of this Memo

This Internet-Draft is submitted to IETF 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 April 16, 2012.

Copyright Notice

Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.

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.

This document may not be modified, and derivative works of it may not be created, except to format it for publication as an RFC or to translate it into languages other than English.

Table of Contents

• 1. Terminology
• 2. Background and Introduction
• 3. UDP messages providing link notification
• 4. Other Possible Blocks
• 5. Uses of these notifications
• 6. Alternative approaches to the problem
• 7. Security Considerations
• 8. IANA Considerations
• 9. Acknowledgements
• 10. References
• 10.1. Normative References
• 10.2. Informative References
• Authors' Addresses

1. Terminology

• attached device - a host (computer) running some type of application or a router.
• uplink - Inbound data on the Radio Frequency (RF) link of the modem.
• downlink - Outbound data on the Radio Frequency (RF) link of the modem.
• upstream - The direction from the modem to the device or application; i.e. away from the RF link.
• downstream - The direction from the device or application to the modem; i.e. toward the RF link.
• LPA - Link Property Advertisement.

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 RFC 2119 [RFC2119].

2. Background and Introduction

Figure 1 illustrates the configuration of a space-based sensor onboard a satellite. The host is co-located with the radio and connected via a serial link. Since all clocking is derived from the modem and its serial link, a rate-based application on the host can run at line rate without overwhelming the modem. Furthermore, congestion control is not of concern if the space/ground link is a dedicated, private link.

      RF                SERIAL   +-----------+
    3 MBPS  +--------+   LINK    |           |
  <-------->| MODEM  |<--------->|   HOST /  |
            +--------+           |APPLICATION|
                                 |           |
                                 +-----------+
 

Space-based Sensor Satellite

Figure 2 illustrates a wireless modem directly connected to a router. Because Ethernet interfaces are plentiful and cheap, the modem and router are connected via high-speed Ethernet. The router needs to know the actual link rate offered by the modem in order to properly set QoS and traffic shaping for that link; simply sending 10/100 Mbps traffic to the modem and having the modem drop most of that traffic, because its outgoing link is slower, is not acceptable. Traffic flows using TCP will autonomously adapt to rate changes by way of the TCP congestion control algorithms. Rate-based protocols may not autonomously adapt - particularly if there is no effective way to implement congestion control such as on a unidirectional link.

     RF               Ethernet    ,---.   
   3 MBPS  +--------+ 100 MBPS   /     \   
 <-------->| MODEM  |<--------->( ROUTER)
           +--------+            \     /  
                                  `---'                                                       
 

Modem/Router Directly Connected

It is possible to configure QoS and shaping on the router's Ethernet interface to match the modem's link rate, effectively extending the modem's link an extra hop to the router. However, such a static configuration is only useful if the modem's link rate is also static. Many modern modems are able to vary their communications according to the channel characteristics they experience, or due to negotiation with the modem at the other end of the link. Examples include the Adaptive Coding and Modulation (ACM) and Variable Coding and Modulation (VCM) used in DVB-S2, and ADSL2's Seamless Rate Adaptation (SRA). Link characteristics may also vary due to layer-2 handovers, e.g. IEEE 802.21 media-independent handoffs.

The router needs to learn about changes in modem link characteristics in order to vary its QoS and shaping configurations to match the current characteristics and get the most from the modem's link. The aim is to make the link between router and modem behave as an extension of the modem's own link.

Consider the topology in Figure 3. Here, an application is running on a host that is behind the router. The application needs to know the downlink status of the modem in order to properly shape the data. For example, the application may be a video camera capable of setting the frame rate relative to the available bandwidth. By having the modem advertise its link properties, the application can autonoumously adapt to the offered rate. Note, in this instance, the host and application are one hop removed from the router. Thus, advertisements of modem properties have to be able to pass beyond the link-local network attachment of the modem.

     RF               Ethernet    ,---.   Ethernet  +-----------+
   3 MBPS  +--------+ 100 MBPS   /     \   10 GBPS  |           |
 <-------->| MODEM  |<--------->( ROUTER)<--------->|   HOST /  |
           +--------+            \     /            |APPLICATION|
                                  `---'             |           |
                                                    +-----------+
                                                    
 

Generic Single Hop Topology

Figure 4 depicts a multi-hop system with one router attached to multiple radios. This configuration shows the need for modem identification, as there may be more than one downstream link that needs to be considered by the router and applications. In addition, the applications that need to shape their traffic are multiple hops from the modems. Knowing the current data rates and whether or not either link is available can enable the applications to make intelligent decisions regarding traffic shaping and when to send. For example: one such application may be to implement reactive fragmentation as soon as the link is down in Disconnection/Delay Tolerant Networking (DTN) [RFC5050].

        RF
     256 KBPS +--------+   Eth
    <-------->| MODEM  |<-----.
              +--------+      |
                              |
                              V
     RF                     ,---.         ,---.       +-----------+
   3 MBPS  +--------+      /     \       /     \      |           |
 <-------->| MODEM  |<--->( ROUTER)<--->( ROUTER)<--->|   HOST /  |
           +--------+ Eth  \     /  Eth  \     / Eth  |APPLICATION|
                            `---'         `---'       |           |
                                                      +-----------+

Generic Multi-hop Topology

One can replace the modem in Figures 1 through 4 with a cryptographic device and have the same basic problem. For example, Figure 5 is the same basic scenario as Figure 3. Figure 5 illustrates a cryptographic device directly connected to a router. Here, both interfaces may be bandwidth with a cryptographic device in between. The cryptographic devices normally operate at line rate. However, during rekeying the offered rate to the normal traffic may be reduced for a period of time or the tunnels may drop resulting in performance hits or momentary loss of communications.

In other traditional IP cryptos it is hard to sense the real rates offered through “the system”. It is feasible for such devices to work this out on their black side – and the red side and simply advertise the “offered rate”. The black side can obtain knowledge of its downstream link state via modem advertisements, router advertisements or probes and pass this on to the red side via approved methods. The red side can then advertise its rate via the link property advertisment protocol.

  
 Effective
 Throughput           Ethernet    ,---.   
   3 MBPS  +--------+ 100 MBPS   /     \   
 <-------->| Crypto |<--------->( ROUTER)
           +--------+            \     /  
                                  `---'                                                       
 

Crypto/Router Directly Connected

The simplest approach to this problem, taken by this draft, is to have the modem advertise its link conditions on its other local interfaces using UDP packets [RFC0768] sent to link-local multicast addresses. This approach requires no explicit configuration setup to provide information to connected devices. UDP is well-understood and widely available, making deployment relatively easy for all types of modems, routers and other connected devices.

To handle advertisements beyond the local interface, Internet Protocol version 4 (IPv4) organizational-scoped multicast and Internet Protocol version 6 (IPv6) site-local multicast MAY be used with no explicit configuration in the modem. Use of IPv4 administratively-scoped multicast and IPv6 site-local multicast could handle both devices that are directly connected to the modem as well as hosts and applications that are multiple hops away [RFC2365] [RFC2373]. However, administratively scoped multicast can have some unusual deployments that may result in unforeseen global traffic. For example, in some implementations, site-local is the global corporation. This results in modem adverts suddenly flooding a planet-wide multi-protocol-label-switched net.

Conversly, to handle advertisements beyond the local interface, unicast packets MAY be sent to known hosts. This does require explicit configuration within the modem, but is simple and straight forward. The end systems where such configurations apply are not expected to be large or complex and likely to consists of only a handful of hosts/applications.

Link property advertisements SHOULD be sent periodically or as notifications of link-layer events when they happen. This falls into the scope of DNA [Detecting Network Attachment] processes [RFC4957].

3. UDP messages providing link notification

The modem sends UDP updates about changing link and interface conditions (i.e. a link rate changes due to a coding change, or the link and its interface go up or down) to connected devices using link-local multicast packets and to upstream hosts and applications using IPv4 administratively-scoped multicast and IPv6 site-local multicast packets and OPTIONALLY unicast packets.

As well as sending on event-triggered updates, the modem SHOULD send periodic advertisements about link conditions, in case new devices have been connected on e.g. a broadcast Ethernet LAN. These updates are sent over both IPv4 and IPv6.

This packet can include multiple Blocks containing different information, where each Block is structured as a Type/Length/Data field. This document defines a single Rate Block which has multiple Link Instance sub-block sections for each input or output interface, each identifying the input or output link interface, and describing the link capacity available (current/maximum/minimum rates in bps). The diagram below shows an example Rate Block with a single (Incoming) Link Instance. If a modem is both IPv4- and IPv6-capable over its link to the router, this information SHOULD be repeated in IPv4 and IPv6 packets received by the attached device.

Format

                      1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 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 
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---
 |       UDP source port         |     UDP destination port      |  
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ B T
 |          UDP length           |         UDP checksum          | L Y
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ O P
 |  Block Type ID (Rate Type 1)  |            Length             | C E
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ K
 |  no. of links | link rate size| modem flags (15 bits unused)|S| 
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---
 |              unique modem interface identifier                | 
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
 |               MTU             |   interface flags |B|F|4|6|U|I|  S
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  U
 |     current link rate (varies) - 32 bits is rate size of 1    |  B
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  -
 |       minimum supported rate - 32 bits is rate size of 1      |  B
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  L
 |       maximum supported rate - 32 bits is rate size of 1      |  O
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  C
 |  IPv4 address of modem's local link interface, if 4 flag set  |  K
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
 |                                                               | 
 |  IPv6 address of modem's local link interface, if 6 flag set  | 
 |                                                               | 
 |                                                               | 
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+---
	

The following fields are defined in this packet's Rate Block:

A bidirectional link on the modem will have incoming and outgoing interfaces that MUST share the same local identifier, and SHOULD share the same local IP address. These interfaces are identified in separate sub-blocks with the I/O flag set appropriately, so that any asymmetry can be described properly. This means that the unique modem interface identifier would be repeated for each sub-block, where one sub-block describes describes Incoming information, and the other Outgoing information. The exception to this is if the link is symmetric, as only one sub-block is required with the Bidirectional Flag (B) set to 1. If a link is down, the D flag is taken as 'zero bit rate' and the 'current' rate indicates the last rate before the modem took the link down. If the minimum and maximum rates are set to zero, this indicates a fixed-speed link whose rate is never altered. An interface does not have to have any IP address.

4. Other Possible Blocks

Other possible blocks, not yet defined here, could express measured error rate, current forward error-coding rate, latency (propagation delay, serialization delay), link MTU size, indicate link-level security mechanisms in use, or provide authentication.

The resource and relative link quality metrics defined in [RFC5578] may also be of use. Unlike [RFC5578], we deliberately define link capacity in exact bps rather than degraded approximate kbps, knowing that for very-low-rate modems, the exact bit rate matters for e.g. call admission control. The lowest link rate that we have encountered is 75bps for submarine applications.

5. Uses of these notifications

An attached device MUST be able to receive link property advertisements via UDP/IP packets sent to the "all routers" multicast address. Information from this message is used to construct or update the QoS and shape policies applied on the interface for traffic directed through the modem's link.

An attached router MAY use this information to update its routing table so that the routing information associated with a route through the modem is either deleted or added or updated with a new metric. Changes in the routing table information are then propagated further.

The modem MAY damp changes to Link Instance information, to prevent advertising transient changes, in line with [RFC4907]. A router MAY also damp responses to frequent changes in Link Instance information received, so that related QoS policies and routing information are not updated until a certain time period has elapsed. This hysteresis would be useful in the case of a rapidly-varying link rate, where the router would stick to the minimum rate seen.

A router may also use this information as input to e.g. Call Admission Control (CAC) functionality to reserve capacity for calls. This can deny registered applications such as telephony call setup etc. in the event of less-than-desired available link capacity through the modem's interface.

To ensure stable operation, upstream hosts and applications MAY use link property advertisements to damp responses to frequent changes in link instance information, e.g. via some form of hysteresis algorithm.

6. Alternative approaches to the problem

The simplest approach to this problem is to have a fixed serial interface between modem and router, with the modem altering the serial rate clock to match the speed of its link, and the router measuring the rate of the received clock. However, fast serial interfaces are unfashionable, and Ethernet now dominates the world.

We considered using ICMP [RFC0792] [RFC4443] to provide this rate information, using the framework for carrying extended information in ICMP messages [RFC4884]. However, this extended information can only be carried in Destination Unreachable and Time Exceeded ICMP messages (for both IPv4 and IPv6) and Parameter Problem (for IPv4 only) ICMP messages. These messages are responses to specific problems, and should not be overloaded for general advertisements. The appropriate ICMP message type would be the obsolete Information Request messge (type 15), though requests are also sent unsolicited for this use. Another factor in preferring UDP over ICMP is that sockets programming for UDP is easier than for ICMP, easing implementation.

Other approaches to this problem have been proposed. None of these approaches addresses the need to extend the modem advertisement beyond the locally attached device.

The authors have outlined an approach leveraging the Access Node Control Protocol, used in the head-ends of DSL networks, within DSLAMs [I-D.floreani-ancp-wireless]. However, ANCP is not lightweight and depends on GSMP, which depends on TCP. The ANCP workgroup is currently focused on the DSL headend, and has yet to extend beyond that environment, while the this link property advertisement proposal is useful at the tail-end in customer networks.

Another approach aimed at improving communication between modems and routers is outlined in [RFC5578]. That approach assumes a PPPoE infrastructure. PPPoE is not always architecturally suitable to network needs, and requiring PPPoE infrastructure and introducing authentication dependencies for what was just a simple local modem-router (or other attached device) problem is overkill. That approach may be suitable as an upgrade to existing PPPoE environments. Adoption of the metrics described in [RFC5578] but with communication separate from PPPoE could be very useful for a wider market, and would provide more information than the link rate information outlined in this draft.

The Dynamic Link Exchange Protocol (DLEP) [I-D.ietf-manet-dlep] also addresses changes in link characteristics such as fluctuations in speed and quality of links due to configuration (in the case of cable/DSL modems), or on a moment-to-moment basis, due to physical phenomena like multipath interference, obstructions, rain fade, etc. DLEP runs between a router and its attached modem devices, allowing the modem to communicate link characteristics as they change, and convergence events (acquisition and loss of potential routing neighbors). However, DLEP is differs from LPA in the following ways:

1 )

DLEP utilizes a session paradigm between the modem device and its associated router.

2 )

DLEP assumes that participating modem devices appear to the router as a transparent bridge - specifically, the assumption is that the destination MAC address for data traffic in any frame emitted by the router should be the MAC address of the next-hop router or end- device, and not the MAC address of any of the intervening modem devices.

3 )

DLEP is designed to operate only over the local-link and does not accommodate systems that are multiple hops away from the modem.

Ethernet pause frames have also been suggested as one way of slowing the Ethernet link to match the modem's link a hop further along [GePause2004]. This approach has the disadvantage of being tied to a particular layer-2 technology, while fine-tuning the pause frames to match the modem's offered link rate has the potential to introduce complex control loops and problems as the paused Ethernet rate approximates the modem link rate and interacts with QoS and shaping delay mechanisms on the router.

DHCP is intended for address configuration of hosts, so is not considered suitable as a way of piggybacking this information.

7. Security Considerations

Link instance advertisements should only be local to connecting devices, and should not be propagated further unless specifically configured to do so using IPv4 administratively-scoped multicast type and and IPv6 site-local multicast or unicast packets. It is assumed that unicast would be site local and under the control of the network administrator. Furthermore, IPsec authentication could be deployed if deemed necessary.

As multicast packets are sent only to link-local multicast addresses, TTL safeguards such as GTSM [RFC5082], which sets TTL to a hard-to-spoof 255, should be unnecessary. Deliberately setting a large TTL on any multicast packet would be unwise if it were to be propagated further.

The decision to use this information more broadly feeds into routing metric updates and policy decisions there; taking the information beyond immediately-connected links becomes a routing problem, and has not been described here.

Some form of authentication of the modem sender is required to prevent spoofing from other local devices. It should be possible to configure the UDP port number used by the router and modem, to avoid attacks on a well-known port assigned by IANA.

Separation of secure and insecure networks, with the modem on the insecure side, wil prevent applications from trusting any information received from the modem.

8. IANA Considerations

IANA must allocate a UDP port for use.

IANA must allocate a new IPv4 administratively-scoped multicast address and IPv6 site-local multicast address for LPA advertisements.

Multicast packets are sent to the well-known link-local "all routers" multicast addresses (224.0.0.2 and ff02::2). No further addresses are needed. Unicast link property advertisement are deployment-specific.

9. Acknowledgements

Many thanks to Dan Shell. Much useful, practical knowledge was gained from laboratory deployments of MANET modems which implemented RFC 4938, PPP Over Ethernet (PPPoE) Extensions for Credit Flow and Link Metrics (obsoleted by RFC 5578).

This document draws greatly from previous work performed by Lloyd Wood, Rajiv Asati and Daniel Floreani, particularly [I-D.wood-dna-link-properties-advertisement].

Work on this document at NASA's Glenn Research Center was funded by NASA's Earth Science Technology Office (ESTO).

10. References

10.1. Normative References

10.2. Informative References

Authors' Addresses