Network Working Group W. Ivancic Internet-Draft NASA GRC Intended status: Experimental L. Wood Expires: April 16, 2012 University of Surrey R. Asati D. Floreani Cisco Systems D. Shell DShell Net Arch October 14, 2011 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. 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 April 16, 2012 [Page 1] Internet-Draft Modem LPA October 2011 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. 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 April 16, 2012 [Page 2] Internet-Draft Modem LPA October 2011 Table of Contents 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Background and Introduction . . . . . . . . . . . . . . . . . 4 3. UDP messages providing link notification . . . . . . . . . . 8 4. Other Possible Blocks . . . . . . . . . . . . . . . . . . . . 11 5. Uses of these notifications . . . . . . . . . . . . . . . . . 12 6. Alternative approaches to the problem . . . . . . . . . . . . 12 7. Security Considerations . . . . . . . . . . . . . . . . . . . 14 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 10.1. Normative References . . . . . . . . . . . . . . . . . . 15 10.2. Informative References . . . . . . . . . . . . . . . . . 16 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 Ivancic, et al. Expires April 16, 2012 [Page 3] Internet-Draft Modem LPA October 2011 1. 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]. 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 1 Figure 2 illustrates a wireless modem directly connected to a router. Because Ethernet interfaces are plentiful and cheap, the modem and Ivancic, et al. Expires April 16, 2012 [Page 4] Internet-Draft Modem LPA October 2011 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 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 Ivancic, et al. Expires April 16, 2012 [Page 5] Internet-Draft Modem LPA October 2011 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]. 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 Ivancic, et al. Expires April 16, 2012 [Page 6] Internet-Draft Modem LPA October 2011 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 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. Ivancic, et al. Expires April 16, 2012 [Page 7] Internet-Draft Modem LPA October 2011 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. Ivancic, et al. Expires April 16, 2012 [Page 8] Internet-Draft Modem LPA October 2011 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 April 16, 2012 [Page 9] Internet-Draft Modem LPA October 2011 +---------------+---------------------------------------------------+ | 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 April 16, 2012 [Page 10] Internet-Draft Modem LPA October 2011 | 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. 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] Ivancic, et al. Expires April 16, 2012 [Page 11] Internet-Draft Modem LPA October 2011 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. Ivancic, et al. Expires April 16, 2012 [Page 12] Internet-Draft Modem LPA October 2011 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 April 16, 2012 [Page 13] Internet-Draft Modem LPA October 2011 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 Ivancic, et al. Expires April 16, 2012 [Page 14] Internet-Draft Modem LPA October 2011 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 [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 April 16, 2012 [Page 15] Internet-Draft Modem LPA October 2011 10.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., Jury, S., and D. Satterwhite, "Dynamic Link Exchange Protocol (DLEP)", draft-ietf-manet-dlep-01 (work in progress), May 2011. [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 April 16, 2012 [Page 16] Internet-Draft Modem LPA October 2011 [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 Centre for Communication Systems Research, University of Surrey Guildford, Surrey GU2 7XH United Kingdom Phone: +44-1483-689123 Email: L.Wood@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 April 16, 2012 [Page 17] Internet-Draft Modem LPA October 2011 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 April 16, 2012 [Page 18]