[Search] [txt|pdf|bibtex] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01                                                         
Network Working Group                                            L. Wood
Internet-Draft                                                  R. Asati
Intended status: Experimental                                D. Floreani
Expires: January 15, 2009                                  Cisco Systems
                                                           July 14, 2008

           Link properties advertisement from modem to router

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-

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

   The list of current Internet-Drafts can be accessed at

   The list of Internet-Draft Shadow Directories can be accessed at

   This Internet-Draft will expire on January 15, 2009.


   Routers are increasingly connected to a variety of smart modems.
   Such a modem's incoming and outgoing link rates can be varied over
   time with adaptive coding and modulation to suit the channel
   characteristics.  The link rate and conditions offered by the modem
   to connected devices therefore vary.  For connected devices to
   condition traffic and get the most out of the modem's link capacity,
   they need to know the modem's link conditions.  This document
   describes one simple method for the modem to advertise link rate and
   other characteristics, via UDP messages, and discusses alternative
   approaches to communicating this information.

Wood, et al.            Expires January 15, 2009                [Page 1]

Internet-Draft        Modem/router link properties             July 2008

Table of Contents

   1.  Background and Introduction  . . . . . . . . . . . . . . . . .  3
   2.  UDP messages providing link notifications  . . . . . . . . . .  3
   3.  Other possible blocks  . . . . . . . . . . . . . . . . . . . .  6
   4.  Router use of these notifications  . . . . . . . . . . . . . .  7
   5.  Other approaches to the problem  . . . . . . . . . . . . . . .  7
   6.  Security Considerations  . . . . . . . . . . . . . . . . . . .  8
   7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  9
   8.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . .  9
   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . .  9
     9.1.  Normative References . . . . . . . . . . . . . . . . . . .  9
     9.2.  Informative References . . . . . . . . . . . . . . . . . .  9
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10
   Intellectual Property and Copyright Statements . . . . . . . . . . 12

Wood, et al.            Expires January 15, 2009                [Page 2]

Internet-Draft        Modem/router link properties             July 2008

1.  Background and Introduction

   Consider a wireless modem connected to a router.  The modem and
   router are connected via high-speed Ethernet, because Ethernet
   interfaces are plentiful and cheap.  The router needs to know the
   link rate offered by the modem in order to set QoS and shaping
   usefully for that link; simply sending 10/100Mbps traffic to the
   modem and having the modem drop most of that traffic is not optimal.

   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.

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

   Updates are sent periodically or as notifications of link-layer
   events when they happen.  This falls into the scope of DNA [Detecting
   Network Attachment] processes [RFC4957].

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   document are to be interpreted as described in RFC 2119.  [RFC2119]

2.  UDP messages providing link notifications

   The modem sends UDP updates, about changing link and interface
   conditions, to connected routers, i.e. a link rate changes due to a

Wood, et al.            Expires January 15, 2009                [Page 3]

Internet-Draft        Modem/router link properties             July 2008

   coding change, or the link and its interface go up or down.

   As well as sending on event-triggered updates, the modem SHOULD send
   periodic advertisements about link conditions, in case new router
   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 router.

                        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      |
   |          UDP length           |         UDP checksum          |
   |      Rate Type Block ID (1)   |            Length             |
   +  no. of links | link rate size| modem flags (15 bits unused)|S|
   +              unique modem interface identifier                |
   +               interface flags (28 bits unused)        |4|6|U|I|
   |     current link rate (varies) - 32 bits is rate size of 1    |
   |       minimum supported rate - 32 bits is rate size of 1      |
   |       maximum supported rate - 32 bits is rate size of 1      |
   |  IPv4 address of modem's local link interface, if 4 flag set  |
   |                                                               |
   |  IPv6 address of modem's local link interface, if 6 flag set  |
   |                                                               |
   |                                                               |

Wood, et al.            Expires January 15, 2009                [Page 4]

Internet-Draft        Modem/router link properties             July 2008

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

   | Name       | Value                                                |
   | Type Block | 1 for Rate Blocks.  Permits future definition of     |
   | ID         | other Blocks conveying different types of            |
   |            | information.                                         |
   | Length     | Length of the Block data, until the next Block or    |
   |            | end of packet.                                       |
   | no. of     | total number of input or output interface sub-blocks |
   | links      | listed in this Rate Block.                           |
   | link rate  | The number of 32-bit words used for bps rate fields. |
   | size       | A value of 1 equates to 32 bits, which can describe  |
   |            | rates up to 4Gibps, 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 MTU would be        |
   |            | exceeded by a single Rate Block, multiple packets    |
   |            | are sent with separate Rate Blocks with the Some     |
   |            | flag set.                                            |
   | unique     | Identifies the modem's local incoming or outgoing    |
   | modem      | link interface to disambiguate it from other links   |
   | interface  | offered by the modem.                                |
   | identifier |                                                      |
   | interface  | A 32-bit field with flags describing each individual |
   | flags      | link.  Unused flag bits MUST be set to zero.  Four   |
   |            | bits are currently in use.                           |
   | 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.                         |
   | 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).                                 |

Wood, et al.            Expires January 15, 2009                [Page 5]

Internet-Draft        Modem/router link properties             July 2008

   | 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    | current offered link capacity in bps.  When the link |
   | link rate  | rate size is 1 this is a 32-bit word indicating the  |
   |            | range 0-4 Gibps.                                     |
   | Min rate   | minimum supported link capacity in bps, specified as |
   |            | the current link rate is.                            |
   | Max rate   | maximum supported link capacity in bps, specified as |
   |            | the current link rate is.                            |
   | IPv4       | IPv4 address of modem, if present as indicated by    |
   | address    | the IPv4 flag.                                       |
   | IPv6       | IPv6 address of modem, if present as indicated by    |
   | address    | 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 common
   interface identifier would be repeated for each sub-block, where one
   sub-block describes describes Incoming information, and the other
   Outgoing information.  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 ia never
   altered.  An interface does not have to have any IP address.

3.  Other possible blocks

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

   The resource and relative link quality metrics defined in [RFC4938]
   may also be of use.  Unlike [RFC4938], 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.

Wood, et al.            Expires January 15, 2009                [Page 6]

Internet-Draft        Modem/router link properties             July 2008

4.  Router use of these notifications

   The router MUST be able to receive these UDP/IP packets sent to the
   "all routers" multicast address.  Information from this message is
   used to construct or update the QoS and shaping policies applied on
   the interface for traffic directed to the leads to the modem's link.

   The 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 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].  The 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 would be useful in the case of a rapidly-varying link rate,
   where the router would stick to the minimum rate seen.

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

5.  Other 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 in 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.

Wood, et al.            Expires January 15, 2009                [Page 7]

Internet-Draft        Modem/router link properties             July 2008

   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 this proposal is also useful at
   the tail-end in customer networks.

   Another approach aimed at improving communication between modems and
   routers is outlined in [RFC4938] and [I-D.bberry-rfc4938bis].  That
   approach assumes a PPPoE infrastructure.  PPPoE is not always
   architecturally suitable to network needs, and requiring a global
   PPPoE infrastructure and introducing authentication dependencies for
   what was just a simple local modem-router problem is overkill.  That
   approach may be suitable as an upgrade to existing PPPoE
   environments.  Adoption of the metrics described in [RFC4938] 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.

   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.

6.  Security Considerations

   Link instance advertisements should only be local to connecting
   devices, and should not be propagated further.

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

Wood, et al.            Expires January 15, 2009                [Page 8]

Internet-Draft        Modem/router link properties             July 2008

   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.

7.  IANA Considerations

   IANA must allocate a UDP port for use.

   Packets are sent to the well-known link-local "all routers" multicast
   addresses ( and ff02::2).  No further addresses are needed.

8.  Acknowledgements

   We thank our colleagues at Cisco Systems for vigorous discussion on
   this topic.

   (We briefly considered calling this UDP message format Modem To
   Router Link Advertisement, or MoToRoLA, but thought better of it.
   Suggestions for a better name are welcome.)

9.  References

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

9.2.  Informative References

              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.

              Berry, B., Ratliff, S., Paradise, E., Kaiser, T., and M.
              Adams, "PPP Over Ethernet (PPPoE) Extensions for Credit
              Flow and Link Metrics", draft-bberry-rfc4938bis-00 (work
              in progress), April 2008.

Wood, et al.            Expires January 15, 2009                [Page 9]

Internet-Draft        Modem/router link properties             July 2008

              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.

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

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

   [RFC4884]  Bonica, R., Gan, D., Tappan, D., and C. Pignataro,
              "Extended ICMP to Support Multi-Part Messages", RFC 4884,
              April 2007.

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

   [RFC4938]  Berry, B. and H. Holgate, "PPP Over Ethernet (PPPoE)
              Extensions for Credit Flow and Link Metrics", RFC 4938,
              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.

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

Authors' Addresses

   Lloyd Wood
   Cisco Systems
   11 New Square Park, Bedfont Lakes
   Feltham, Middlesex  TW14 8HA
   United Kingdom

   Phone: +44-20-8824-4236
   Email: lwood@cisco.com

Wood, et al.            Expires January 15, 2009               [Page 10]

Internet-Draft        Modem/router link properties             July 2008

   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

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

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

Wood, et al.            Expires January 15, 2009               [Page 11]

Internet-Draft        Modem/router link properties             July 2008

Full Copyright Statement

   Copyright (C) The IETF Trust (2008).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an

Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at

Wood, et al.            Expires January 15, 2009               [Page 12]