Internet DRAFT - draft-ivancic-mobopts-modemlpa
draft-ivancic-mobopts-modemlpa
Network Working Group W. Ivancic
Internet-Draft NASA GRC
Intended status: Experimental L. Wood
Expires: October 14, 2012 University of Surrey
R. Asati
D. Floreani
Cisco Systems
D. Shell
DShell Net Arch
April 12, 2012
Modem Link Properties Advertisement Protocol
draft-ivancic-mobopts-modemlpa-01
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 October 14, 2012 [Page 1]
Internet-Draft Modem LPA April 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 October 14, 2012.
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 October 14, 2012 [Page 2]
Internet-Draft Modem LPA April 2012
Table of Contents
1. Document Status / Update . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Background and Introduction . . . . . . . . . . . . . . . . . 5
4. UDP messages providing link notification . . . . . . . . . . 8
5. Other Possible Blocks . . . . . . . . . . . . . . . . . . . . 12
6. Uses of these notifications . . . . . . . . . . . . . . . . . 13
7. Alternative approaches to the problem . . . . . . . . . . . . 13
8. Security Considerations . . . . . . . . . . . . . . . . . . . 15
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
11.1. Normative References . . . . . . . . . . . . . . . . . . 16
11.2. Informative References . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18
Ivancic, et al. Expires October 14, 2012 [Page 3]
Internet-Draft Modem LPA April 2012
1. Document Status / Update
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 fullfil 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 Advertisment 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
signalling required for the DLEP client/server session to perform the
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].
Ivancic, et al. Expires October 14, 2012 [Page 4]
Internet-Draft Modem LPA April 2012
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.
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
Ivancic, et al. Expires October 14, 2012 [Page 5]
Internet-Draft Modem LPA April 2012
configuration is only useful if the modem's link rate is also static.
Many modern modems are able to vary their communications according to
the channel characteristics they experience, or due to negotiation
with the modem at the other end of the link. Examples include the
Adaptive Coding and Modulation (ACM) and Variable Coding and
Modulation (VCM) used in DVB-S2, and ADSL2's Seamless Rate Adaptation
(SRA). Link characteristics may also vary due to layer-2 handovers,
e.g. IEEE 802.21 media-independent handoffs.
The router needs to learn about changes in modem link characteristics
in order to vary its QoS and shaping configurations to match the
current characteristics and get the most from the modem's link. The
aim is to make the link between router and modem behave as an
extension of the modem's own link.
Consider the topology in Figure 3. Here, an application is running
on a host that is behind the router. The application needs to know
the downlink status of the modem in order to properly shape the data.
For example, the application may be a video camera capable of setting
the frame rate relative to the available bandwidth. By having the
modem advertise its link properties, the application can
autonoumously adapt to the offered rate. Note, in this instance, the
host and application are one hop removed from the router. Thus,
advertisements of modem properties have to be able to pass beyond the
link-local network attachment of the modem.
RF Ethernet ,---. Ethernet +-----------+
3 MBPS +--------+ 100 MBPS / \ 10 GBPS | |
<-------->| MODEM |<--------->( ROUTER)<--------->| HOST / |
+--------+ \ / |APPLICATION|
`---' | |
+-----------+
Generic Single Hop Topology
Figure 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
Ivancic, et al. Expires October 14, 2012 [Page 6]
Internet-Draft Modem LPA April 2012
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
interfaces may be high-bandwidth Ethernet interfaces with a
cryptographic device in between. 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, this 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 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.
Ivancic, et al. Expires October 14, 2012 [Page 7]
Internet-Draft Modem LPA April 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 October 14, 2012 [Page 8]
Internet-Draft Modem LPA April 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 October 14, 2012 [Page 9]
Internet-Draft Modem LPA April 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 October 14, 2012 [Page 10]
Internet-Draft Modem LPA April 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 October 14, 2012 [Page 11]
Internet-Draft Modem LPA April 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 October 14, 2012 [Page 12]
Internet-Draft Modem LPA April 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 October 14, 2012 [Page 13]
Internet-Draft Modem LPA April 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 October 14, 2012 [Page 14]
Internet-Draft Modem LPA April 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 October 14, 2012 [Page 15]
Internet-Draft Modem LPA April 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 October 14, 2012 [Page 16]
Internet-Draft Modem LPA April 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-02 (work in progress),
February 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 October 14, 2012 [Page 17]
Internet-Draft Modem LPA April 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
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 October 14, 2012 [Page 18]
Internet-Draft Modem LPA April 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 October 14, 2012 [Page 19]
