Internet DRAFT - draft-ivancic-manet-modemlpa

draft-ivancic-manet-modemlpa






Network Working Group                                         W. Ivancic
Internet-Draft                                                  NASA GRC
Intended status: Experimental                                    L. Wood
Expires: May 9, 2013                                       Surrey alumni
                                                                R. Asati
                                                             D. Floreani
                                                           Cisco Systems
                                                                D. Shell
                                                         DShell Net Arch
                                                        November 5, 2012


              Modem Link Properties Advertisement Protocol
                    draft-ivancic-manet-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.  This document may not be modified,
   and derivative works of it may not be created, except to format it
   for publication as an RFC and to translate it into languages other
   than English.

   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



Ivancic, et al.            Expires May 9, 2013                  [Page 1]

Internet-Draft                  Modem LPA                  November 2012


   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 May 9, 2013.

Copyright Notice

   Copyright (c) 2012 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.  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.
































Ivancic, et al.            Expires May 9, 2013                  [Page 2]

Internet-Draft                  Modem LPA                  November 2012


Table of Contents

   1.  Document Status / Update . . . . . . . . . . . . . . . . . . .  4
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  5
   3.  Background and Introduction  . . . . . . . . . . . . . . . . .  5
   4.  UDP messages providing link notification . . . . . . . . . . .  9
   5.  Other Possible Blocks  . . . . . . . . . . . . . . . . . . . . 13
   6.  Uses of these notifications  . . . . . . . . . . . . . . . . . 14
   7.  Alternative approaches to the problem  . . . . . . . . . . . . 14
   8.  Security Considerations  . . . . . . . . . . . . . . . . . . . 16
   9.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 17
   10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17
   11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
     11.1.  Normative References  . . . . . . . . . . . . . . . . . . 17
     11.2.  Informative References  . . . . . . . . . . . . . . . . . 18
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19



































Ivancic, et al.            Expires May 9, 2013                  [Page 3]

Internet-Draft                  Modem LPA                  November 2012


1.  Document Status / Update

   This document was originally submitted as to the IRTF mobopts
   research group as an individual submission
   draft-ivancic-mobopts-modemlpa-01.  That research group as recently
   closed down.  The new submission is to manet as
   draft-ivancic-manet-modemlpa-00.

   A PERL script, modem-LPA-packetgen.pl, has been placed in sourceforge
   as open source software.  The PERL script generates modemLPA packets
   base on the modem link property advertisement draft,
   "draft-ivancic-mobopts-modemlpa-01".  NOTE. the IRTF mobopts research
   group has recently closed down.  Futher advancements of the
   specification will be within some other yet to be determined group.

   The script was used to demonstrate modemLPA by controlling the rate
   on a file transfer protocol.  The file transfer protocol used was
   Saratoga and is implemented in a PERL script.  The Saratoga PERL
   script is available on SourceForge.  Search for saratoga and the
   script will be in the directory saratoga_v1_perl.

   This script and the Saratoga implementation currently use a multicast
   address of 226.1.1.2.  The all routers address of 224.0.0.2 is
   suppose to be used, but the particular Linux machines we where
   running on did not want to pass 224.0.0.2 and we did not have
   sufficient time to determine why.

   Eventually, we hope to include code for GNU radios that implement
   modemLPA.

   Code is available for modemLPA from
   http://sourceforge.net/projects/modemlpa/

   Code is available for Saratoga from
   http://saratoga.cvs.sourceforge.net/viewvc/saratoga/

   The authors of modemLPA have been in discussion with the authors of
   "Dynamic Link Exchange Protocol (DLEP)" [I-D.ietf-manet-dlep] to
   determine if DLEP will fulfill the needs that ModemLPA is targeted
   at.  DLEP is currently a client/server session oriented protocol that
   provides link layer information to directly connected devices -
   generally routers.  The Modem Link Property Advertisement protocol
   broadcasts link status notifications to directly-attached devices and
   devices or applications that may be multiple hops away from the modem
   (or other sending device).

   It should be possible to use the DLEP message formats without all the
   signaling required for the DLEP client/server session to perform the



Ivancic, et al.            Expires May 9, 2013                  [Page 4]

Internet-Draft                  Modem LPA                  November 2012


   functions addressed in this draft.  The modem would simply provide
   link states out via multicast or unicast UDP datagrams (DLEP-Lite).
   Whether or not this is a good idea, or acceptable to the manet group,
   is yet to be determined.

   This draft is unchanged from -00 except for this notification.  A
   determination should be completed within the next six months to
   continue with modemLPA or use DLEP.


2.  Terminology

   o  attached device - a host (computer) running some type of
      application or a router.

   o  uplink - Inbound data on the Radio Frequency (RF) link of the
      modem.

   o  downlink - Outbound data on the Radio Frequency (RF) link of the
      modem.

   o  upstream - The direction from the modem to the device or
      application; i.e. away from the RF link.

   o  downstream - The direction from the device or application to the
      modem; i.e. toward the RF link.

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


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








Ivancic, et al.            Expires May 9, 2013                  [Page 5]

Internet-Draft                  Modem LPA                  November 2012


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

                       Space-based Sensor Satellite

                                 Figure 1

   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

                                 Figure 2

   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



Ivancic, et al.            Expires May 9, 2013                  [Page 6]

Internet-Draft                  Modem LPA                  November 2012


   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 3

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












Ivancic, et al.            Expires May 9, 2013                  [Page 7]

Internet-Draft                  Modem LPA                  November 2012


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

                        Generic Multi-hop Topology

                                 Figure 4

   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 high-bandwidth Ethernet interfaces with a
   cryptographic device inbetween.  Those interfaces' bandwidths may not
   match.  For example, the red-side interface may operate at 100 Mbps
   with the black-side interface is operating at 10 Mbps.  The
   cryptographic devices normally operate at line rate, thus we may have
   a rate-mismatch problem.  Also, 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 can 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.












Ivancic, et al.            Expires May 9, 2013                  [Page 8]

Internet-Draft                  Modem LPA                  November 2012


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

                     Crypto/Router Directly Connected

                                 Figure 5

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


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



Ivancic, et al.            Expires May 9, 2013                  [Page 9]

Internet-Draft                  Modem LPA                  November 2012


   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.































Ivancic, et al.            Expires May 9, 2013                 [Page 10]

Internet-Draft                  Modem LPA                  November 2012


   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:



















Ivancic, et al.            Expires May 9, 2013                 [Page 11]

Internet-Draft                  Modem LPA                  November 2012


   +---------------+---------------------------------------------------+
   | Name          | Value                                             |
   +---------------+---------------------------------------------------+
   | Type Block ID | ID = 1 for rate blocks.  Permits future           |
   |               | definition of other blocks conveying different    |
   |               | types of information.                             |
   | Length        | Length of the Block data, until the next Block or |
   |               | end of packet.                                    |
   | no. of links  | Total number of input or output interface         |
   |               | sub-blocks listed in this Rate Block              |
   | link rate     | The number of 32-bit words used for bps rate      |
   | size          | fields.  A value of 1 equates to 32 bits, which   |
   |               | can describe rates up to 4 Gbps, and is           |
   |               | sufficient for most current modems.  This is the  |
   |               | first item in the Rate Block's Value data.        |
   | modem         | Flags that can describe properties of the modem.  |
   | flags         | Unused flag fields MUST be set to zero.  One bit  |
   |               | is currently in use.                              |
   | S/A flag      | Indicates whether the Rate Block contains fields  |
   |               | describing Some modem interfaces (flag set to 1), |
   |               | or All modem interfaces (0).  Periodic messages   |
   |               | SHOULD describe All interfaces.  Updates          |
   |               | triggered by an event on an interface, e.g. a     |
   |               | link going down, where nothing else has changed,  |
   |               | would be a Some update describing only that       |
   |               | interface.  If a complex modem contains so many   |
   |               | interfaces that link MTU would be exceeded by a   |
   |               | single Rate Block, multiple packets are sent with |
   |               | separate Rate Blocks with the Some flag set.      |
   | unique modem  | Identifies the modem's local incoming or outgoing |
   | interface     | link interface to disambiguate it from other      |
   | identifier    | links offered by the modem.                       |
   | MTU           | A 16-bit field advertising the Maximum            |
   |               | Transmission Unit on each individual link.        |
   | interface     | A 16-bit field with flags describing each         |
   | flags         | individual link.  Unused flag bits MUST be set to |
   |               | zero.  Six bits are currently in use.             |
   | Bidirectional | If set, on this interface the advertised rate     |
   | flag          | applies to both inbound and outbound traffic as   |
   |               | does the link up/down status.                     |
   | Fix Rate flag | If set, this interface is a non-varying fixed     |
   |               | rate for the specified interface and direction.   |
   |               | The rate is specified by the current rate.        |
   | IPv4 flag     | If set, an IPv4 address for the interface is      |
   |               | appended to the description.                      |
   | IPv6 flag     | If set, an IPv6 address for the interface is      |
   |               | appended to the description.                      |




Ivancic, et al.            Expires May 9, 2013                 [Page 12]

Internet-Draft                  Modem LPA                  November 2012


   | U/D flag      | Indicates whether the link interface is currently |
   |               | Up or Down, i.e. accepting traffic (up, value 1), |
   |               | or not (down, value 0).                           |
   | I/O flag      | Indicates whether the rate information given for  |
   |               | the interface describes the incoming rate to the  |
   |               | modem (and router) or the outgoing rate from the  |
   |               | modem (and router) over the modem's link to the   |
   |               | remote modem.  Describing outgoing rates is most  |
   |               | likely to be useful for shaping traffic to be     |
   |               | passed to the modem.  Incoming is 1, Outgoing is  |
   |               | 0.                                                |
   | Current link  | current offered link capacity in bps.  When the   |
   | rate          | linkrate size is 1 this is a 32-bit word          |
   |               | indicating the range 0-4 Gibps.                   |
   | Min rate      | minimum supported link capacity in bps, specified |
   |               | asthe current link rate is.                       |
   | Max rate      | maximum supported link capacity in bps, specified |
   |               | as the current link rate is.                      |
   | IPv4 address  | IPv4 address of modem, if present as indicated by |
   |               | the IPv4 flag.                                    |
   | IPv6 address  | IPv6 address of modem, if present as indicated by |
   |               | the IPv6 flag.                                    |
   +---------------+---------------------------------------------------+

   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.


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



Ivancic, et al.            Expires May 9, 2013                 [Page 13]

Internet-Draft                  Modem LPA                  November 2012


   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.


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


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




Ivancic, et al.            Expires May 9, 2013                 [Page 14]

Internet-Draft                  Modem LPA                  November 2012


   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:





Ivancic, et al.            Expires May 9, 2013                 [Page 15]

Internet-Draft                  Modem LPA                  November 2012


   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.


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



Ivancic, et al.            Expires May 9, 2013                 [Page 16]

Internet-Draft                  Modem LPA                  November 2012


   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.


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


10.  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).


11.  References

11.1.  Normative References

   [RFC0768]  Postel, J., "User Datagram Protocol", STD 6, RFC 768,
              August 1980.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.





Ivancic, et al.            Expires May 9, 2013                 [Page 17]

Internet-Draft                  Modem LPA                  November 2012


11.2.  Informative References

   [GePause2004]
              Ge, A. and G. Chiruvolu, "Diffserv Compatible Extended
              Pause (DiffPause) for Fair Congestion Control in Metro-
              Ethernet", IEEE International Conference on
              Communications, vol. 2 pp. 1248-1252 , June 2004.

   [I-D.floreani-ancp-wireless]
              Floreani, D. and L. Wood, "Extension of ANCP for Satellite
              and Terrestrial Wireless Modem Networks",
              draft-floreani-ancp-wireless-00 (work in progress),
              June 2007.

   [I-D.ietf-manet-dlep]
              Ratliff, S., Cisco, C., Harrison, G., Satterwhite, D., and
              S. Jury, "Dynamic Link Exchange Protocol (DLEP)",
              draft-ietf-manet-dlep-03 (work in progress), August 2012.

   [I-D.wood-dna-link-properties-advertisement]
              Wood, L., Asati, R., and D. Floreani, "Link properties
              advertisement from modem to router",
              draft-wood-dna-link-properties-advertisement-01 (work in
              progress), July 2008.

   [RFC0792]  Postel, J., "Internet Control Message Protocol", STD 5,
              RFC 792, September 1981.

   [RFC2365]  Meyer, D., "Administratively Scoped IP Multicast", BCP 23,
              RFC 2365, July 1998.

   [RFC2373]  Hinden, R. and S. Deering, "IP Version 6 Addressing
              Architecture", RFC 2373, July 1998.

   [RFC4443]  Conta, A., Deering, S., and M. Gupta, "Internet Control
              Message Protocol (ICMPv6) for the Internet Protocol
              Version 6 (IPv6) Specification", RFC 4443, March 2006.

   [RFC4907]  Aboba, B., "Architectural Implications of Link
              Indications", RFC 4907, June 2007.

   [RFC4957]  Krishnan, S., Montavont, N., Njedjou, E., Veerepalli, S.,
              and A. Yegin, "Link-Layer Event Notifications for
              Detecting Network Attachments", RFC 4957, August 2007.

   [RFC5050]  Scott, K. and S. Burleigh, "Bundle Protocol
              Specification", RFC 5050, November 2007.




Ivancic, et al.            Expires May 9, 2013                 [Page 18]

Internet-Draft                  Modem LPA                  November 2012


   [RFC5082]  Gill, V., Heasley, J., Meyer, D., Savola, P., and C.
              Pignataro, "The Generalized TTL Security Mechanism
              (GTSM)", RFC 5082, October 2007.

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


Authors' Addresses

   William Ivancic
   NASA Glenn Research Center
   21000 Brookpark Road
   Cleveland, Ohio  44135
   United States

   Phone: +1-216-433-3494
   Email: william.d.ivancic@nasa.gov


   Lloyd Wood
   University of Surrey alumni
   Sydney, New South Wales
   Australia

   Email: L.Wood@society.surrey.ac.uk


   Rajiv Asati
   Cisco Systems
   7025-6 Kit Creek Road
   Research Triangle Park, North Carolina  27709-4987
   United States

   Phone: +1-919-392-8558
   Email: rajiva@cisco.com














Ivancic, et al.            Expires May 9, 2013                 [Page 19]

Internet-Draft                  Modem LPA                  November 2012


   Daniel Floreani
   Cisco Systems
   Westpac House
   91 King William Street
   Adelaide, South Australia  5000
   Australia

   Phone: +61-8-8124-2206
   Email: danielf@cisco.com


   Dan Shell
   DSHELL Network  Architectures, LLC
   20725 Germantown Drive
   Fairview Park, OH  44126
   USA

   Phone: +1-216-970-8260
   Email: dshellwireless@gmail.com
































Ivancic, et al.            Expires May 9, 2013                 [Page 20]