Network Working Group L. Wood
Internet-Draft R. Asati
Intended status: Experimental D. Floreani
Expires: January 8, 2009 Cisco Systems
July 7, 2008
Link properties advertisement from modem to router
draft-wood-dna-link-properties-advertisement-00
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-
Drafts.
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
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on January 8, 2009.
Abstract
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 8, 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 . . . . . . . . . . . . . . 6
5. Other approaches to the problem . . . . . . . . . . . . . . . 7
6. Security Considerations . . . . . . . . . . . . . . . . . . . 8
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9
9.1. Normative References . . . . . . . . . . . . . . . . . . . 9
9.2. Informative References . . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10
Intellectual Property and Copyright Statements . . . . . . . . . . 11
Wood, et al. Expires January 8, 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 DVB-
S2's Adaptive Coding and Modulation (ACM), and ADSL2's Seamless Rate
Adaptation (SRA).
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",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
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
coding change, or the link and its interface go up or down.
Wood, et al. Expires January 8, 2009 [Page 3]
Internet-Draft Modem/router link properties July 2008
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 separately for IPv4 (describing IPv4-capable
links) and IPv6 (describing IPv6-capable links). An interface that
is capable of carrying IPv4 and IPv6 packets will be described in
both IPv4 and IPv6 packets.
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, the type of link
capacity offered (fixed or varying) and link capacity available (rate
in bps). The diagram below shows an example packet describing IPv4-
capable links. An equivalent packet for IPv6-capable links will have
longer addresses for each modem link and interface.
The UDP packet format used, showing the Rate Block, is as follows:
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 (unused) |S|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+
+ IP address of modem's local link interface (IPv4) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ interface flags (unused) |F|U|I|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ fixed link rate +
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ IP address of modem's local link interface (IPv4) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ link description flags (unused) |V|D|O|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ current link rate (varies) +
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ minimum supported rate +
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ maximum supported rate +
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Wood, et al. Expires January 8, 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 | 1 for Rate Blocks. Permits future definition of |
| Block 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 fixed and varying links listed in the |
| links | 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 4Gbps, 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 | These are currently unused. Unused flag fields MUST |
| | be set to zero. |
| S/A flag | indicates whether the Rate Block contains fields |
| | describing Some modem interfaces, or All modem |
| | interfaces. 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, multiple |
| | packets are sent with the Some flag set. |
| IP | Identifies the modem's local incoming or outgoing |
| address | link interface to disambiguate it from other links |
| of | offered by the modem. For unnumbered interfaces or |
| modem's | modems supporting only one link interface, this can |
| link | be the address of the interface on the subnet to the |
| interface | router instead. |
| interface | A 32-bit field with flags describing each individual |
| flags | link. Unused flag bits MUST be set to zero. |
| F/V flag | Indicates whether a link is Fixed at one rate, or |
| | Varying with additional minimum/maximum rates that |
| | are described in three following fields, rather than |
| | one. |
| U/D flag | Indicates whether the link interface is currently Up |
| | or Down, i.e. accepting traffic (up), or not (down). |
| 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. |
| | Describing outgoing rates is most likely to be useful |
| | for shaping traffic to be passed to the modem. |
Wood, et al. Expires January 8, 2009 [Page 5]
Internet-Draft Modem/router link properties July 2008
| Current | current offered link capacity in bps (fixed or |
| link rate | varying) |
| Min rate | minimum supported link capacity in bps (varying only) |
| Max rate | maximum supported link capacity in bps (varying only) |
+-----------+-------------------------------------------------------+
If a modem interface is to a fixed-speed link, minimum and maximum
rates need not be sent. A bidirectional modem interface has incoming
and outgoing interfaces that should share the same local IP address
facing the modem link. These interfaces are identified in separate
sub-blocks with the I/O flag set appropriately, so that any asymmetry
can be described properly, meaning that the shared IP address would
be repeated for each sub-block. 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. Current/min/max rates MUST
NOT ever be set to zero.
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 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.
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
Wood, et al. Expires January 8, 2009 [Page 6]
Internet-Draft Modem/router link properties July 2008
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.
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. Another factor
in preferring UDP is that sockets programming for UDP is easier than
for ICMP, making implementation easier.
Other approaches to this problem have been proposed. The authors
outlined an approach leveraging the Access Node Control Protocol,
used in the head-ends of DSL networks in 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.
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
Wood, et al. Expires January 8, 2009 [Page 7]
Internet-Draft Modem/router link properties July 2008
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 such a multicast
packet would be unwise if it was 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.
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 (224.0.0.2 and ff02::2). No further addresses are needed.
8. Acknowledgements
We thank our colleagues at Cisco Systems for vigorous discussion on
this topic.
Wood, et al. Expires January 8, 2009 [Page 8]
Internet-Draft Modem/router link properties July 2008
(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
[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.bberry-rfc4938bis]
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.
[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.
[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.
Wood, et al. Expires January 8, 2009 [Page 9]
Internet-Draft Modem/router link properties July 2008
[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
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
Australia
Phone: +61 8 8124 2206
Email: danielf@cisco.com
Wood, et al. Expires January 8, 2009 [Page 10]
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
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
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
http://www.ietf.org/ipr.
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
ietf-ipr@ietf.org.
Wood, et al. Expires January 8, 2009 [Page 11]