Internet DRAFT - draft-floreani-ancp-wireless
draft-floreani-ancp-wireless
Network Working Group D. Floreani
Internet Draft L. Wood
Cisco Systems
Intended status: Experimental June 27, 2007
Expires: December 2007
Extension of ANCP for Satellite and Terrestrial
Wireless Modem Networks
draft-floreani-ancp-wireless-00.txt
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.
This document may only be posted in an Internet-Draft.
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 December 27, 2007.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Floreani and Wood Expires December 27, 2007 [Page 1]
Extension of ANCP for Satellite and Terrestrial Modem Networks June 2007
Abstract
The Access Node Control Protocol (ANCP) has been developed primarily
for the Digital Subscriber Line (DSL) environment, with varying line
conditions where the system that uses ANCP consists of DSLAMs (DSL
access multiplexers) and terminal equipment. In this scenario, the
channel conditions on subscriber lines vary, forcing changes and
adaptations in line rates at the modem equipment, and affecting
services offered. Satellite communications service providers have
very similar issues and are also based around hubs, with satellite
terminals. This application of ANCP could also be extended to point-
to-point radio services in both the satellite and terrestrial domain.
Table of Contents
1. Introduction.................................................. 2
2. Comparison of Satellite Topology to DSL framework............. 4
2.1. Changes to ANCP for Satellite Networks................... 5
3. Alternate ANCP frameworks for other topologies................ 6
3.1. Description of the environment........................... 6
3.2. User-End ANCP for satellite hub-spoke topology........... 6
3.2.1. Changes to ANCP for this framework.................. 7
3.3. Framework for User-End ANCP in a point-to-point topology. 8
3.4. Framework for Bidirectional User-End ANCP................ 8
4. Security Considerations...................................... 10
5. IANA Considerations.......................................... 10
6. Conclusions.................................................. 10
7. Acknowledgments.............................................. 10
8. References................................................... 11
Authors' Addresses.............................................. 11
Intellectual Property Statement................................. 12
Disclaimer of Validity.......................................... 12
1. Introduction
Routers used at the network edge in remote locations often have to be
connected to custom smart adaptive wireless external modems for backhaul
to the terrestrial Internet.
These external modems are separate to the router, and are connected to
the router via a normal interface, commonly Ethernet. Due to the large
choice of purpose-specific modems available, router manufacturers cannot
integrate all these variants into their routers as standard interfaces.
Floreani and Wood Expires December 27, 2007 [Page 2]
Extension of ANCP for Satellite and Terrestrial Modem Networks June 2007
Ethernet is becoming the most popular interface used to connect routers
with custom modems, simply because Ethernet is ubiquitous and cheap.
Many modems are smart in that the modem varies its wireless link speed
to another modem or hub according to current wireless channel
conditions, to get the most out of the channel at all times. Similarly,
the modem at the other end of the link varies its output speed, too, to
adapt to current channel conditions. Smart adaptive wireless modems are
increasingly common.
There are a number of different topologies for satellite networks,
namely point-to-point, mesh, and hub-and-spoke deployments. Just as DSL
modems retrain automatically due to varying channel conditions on the
line, satellite modems can do the same either manually or automatically
as wireless channel conditions vary. Satellite operators can adjust the
amount of Forward Error Coding (FEC) used over the air interface to
provide a particular bit error rate. This affects the overall link
capacity offered to the user. The effects of changes in the access line
rate are identical between satellite and DSL, and traffic shaping is
required to allow the router/modem combination to handle the modem's
current link conditions well.
However, the fixed link to the router's interface is of a fixed speed
(say 100Mbps Ethernet), and the router does not see or know how the
modem's offered speed is varying. There is an 'information gap' across
the fixed link between the router's output interface speed and the
modem's output interface speed on its wireless link. As a result, there
is a gap between how the router configures traffic shaping on its fixed
interface and the traffic shaping that the modem needs for its current
output rate - a fixed QoS/traffic shaping configuration is not suitable
for the varying speeds out the modem's own wireless link.
A smart wireless non-line-of-sight modem might scale, depending on
channel conditions, from, say, 1Mbps to 6Mbps. A satellite modem might
change from 1.5Mbps to 720kbps downstream to the user modem, or from say
32kbps up to 512kbps upstream back to the hub. Meanwhile, that modem
would be connected to the router via a 100Mbps Ethernet link.
Rate limiting on the router's output Ethernet interface is obviously
needed to prevent most of the 100Mbps traffic that that link can carry
being discarded by the modem -- but what limit should the router choose?
The highest speed the modem uses? The most common speed the modem uses?
Rate limiting should vary as the modem's speed varies to adapt to
wireless channel conditions. Many applications auto-tune to the
available rate, but voice traffic needs to be policed to the available
rate and protected from other applications. This requires the shaping
policies for individual classes of traffic to be adaptive as well.
Floreani and Wood Expires December 27, 2007 [Page 3]
Extension of ANCP for Satellite and Terrestrial Modem Networks June 2007
It is important to note that many of the multicast issues being
considered by ANCP are also equally relevant to the satellite and
wireless solutions. Though the technologies applied may be entirely
different in their broadcast and multicast capabilities, the need for
interaction between this type of traffic and allocated bandwidths
upstream is equally important.
The extensions mentioned in this draft are in two sections. Firstly,
modifications that are required to adapt ANCP for satellite hub-and-
spoke deployments, where a satellite hub is equivalent to a DSLAM, and a
satellite terminal is equivalent to the DSL modem.
Secondly, we discuss options that allow the ANCP protocol to be taken
further and adopted by a wider range of applications, namely point-to-
point and mesh topologies. Satellite networks are a prime candidate for
this technique. However, ANCP with modifications could also be suitable
for point-to-point terrestrial wireless networks.
2. Comparison of Satellite Topology to DSL framework
In order to map satellite terminology into the ANCP framework, we
have taken the standard framework from [1] and reproduced it below,
replacing the DSL hardware with satellite hardware.
Terminology:
o SM - Satellite Modem, which includes the RF equipment and
satellite dish, as well as the indoor unit (IDU) that communicates
with a router.
o SAT - Satellite, which is traditionally a bent-pipe layer 1 device
that passes and amplifies the channel, though new satellite
designs are moving to layer-2 and -3 devices over time. We assume
that, though the satellite link enables connectivity, the
satellite is not otherwise involved in or managed in the topology
presented here.
o SAT HUB - Satellite Hub, which terminates the RF signals from the
satellite modems, manages traffic and the MAC layer of the
satellite modems and itself.
Floreani and Wood Expires December 27, 2007 [Page 4]
Extension of ANCP for Satellite and Terrestrial Modem Networks June 2007
+--------+
| Policy |
| Server |
+--------+
|
|
+-----+ +-----+ +--------+ +-----+ +----------+
| SM |---| |---| | | | | |
+-----+ | | | SAT | +---------+ | | | Regional |
| SAT | | HUB |---| Aggreg. |---| NAS |---| Network |
+-----+ | (RF)| | | | Node | | | | |
| SM |---| |---| | +---------+ | | | |
+-----+ +-----+ +--------+ +-----+ +----------+
|-> this portion remains unchanged
Figure 1 DSL vs Satellite Topology.
2.1. Changes to ANCP for Satellite Networks
The following changes to ANCP are anticipated to deal with a wireless
or satellite hub.
o The Tech Type field type indicates the technology to which the
capability extension applies. For access node control in case of
satellite networks, a new "wireless" type is proposed. The value
for this field would need to be reserved. The terminology of
wireless was chosen as it covers the widest range of both
satellite and terrestrial applications.
o The GSMP Event message with PORT UP message type (80) is used for
conveying line attributes to the NAS. The Tech Type field needs
to be extended as above.
o The GSMP Event message with PORT DOWN message type (80) is used
for conveying line state to the NAS. The Tech Type field needs to
be extended as above.
Floreani and Wood Expires December 27, 2007 [Page 5]
Extension of ANCP for Satellite and Terrestrial Modem Networks June 2007
o The "Extension Value" contains one or more TLVs (Type, Length and
Value tuples) to identify an access line and define its
characteristics. A TLV can consist of multiple sub-TLVs. A new
TLV type for wireless link attributes is required. Many of the
sub-TLVs for DSL are reusable for wireless. The following need to
be modified or alternate versions created, to deal with the new
access medium.
. Type (DSL-Type = 0x91) : Defines the type of transmission
system in use.
Value :(Transmission system : ADSL1 = 0x01, ADSL2
=0x02, ADSL2+ = 0x03, VDSL1 = 0x04, VDSL2 = 0x05, SDSL
= 0x06, UNKNOWN = 0x07).
. Type (DSL line state = 0x8F) : The state of the DSL line.
For PORT UP message, at this time, the TLV is optional (since
the message type implicitly conveys the state of the line).
For PORT DOWN, the TLV is mandatory, since it further
communicates the state of the line as IDLE or SILENT.
Value :{ SHOWTIME = 0x01, IDLE = 0x02, SILENT = 0x03 }
3. Alternate ANCP frameworks for other topologies
3.1. Description of the environment
The following sections describe potential applicability of ANCP to
the satellite and terrestrial radio markets. These sections are
presented as a number of options, each expanding the use of ANCP
beyond its original aim of solely supporting DSL, but giving the
protocol much greater applicability outside the DSL market.
3.2. User-End ANCP for satellite hub-spoke topology
While the shaping of traffic from the Satellite Hub (SAT HUB) to the
Satellite Modem (SM) is of importance, in the satellite scenario, the
reverse path also varies due to varying channel conditions. The same
requirements to change traffic shaping are thus also required between
the SM and the CPE Router (RTR).
Floreani and Wood Expires December 27, 2007 [Page 6]
Extension of ANCP for Satellite and Terrestrial Modem Networks June 2007
Terminology:
o RTR - CPE Router
o User-End ANCP - An instance of the ANCP protocol running between
the Satellite Modem (SM) and the CPE Router (RTR).
+--------+
| Policy |
| Server |
+--------+
|
|
+-----+ +-----+ +-----+ +--------+ +-----+
| RTR |-| SM |---| |---| | | |
+-----+ +-----+ | | | SAT | +---------+ | |
| SAT | | HUB |---| Aggreg. |---| NAS |---
+-----+ +-----+ | (RF)| | | | Node | | |
| RTR |-| SM |---| |---| | +---------+ | |
+-----+ +-----+ +-----+ +--------+ +-----+
User-End Access Node Access Node Control Mechanism
Control Mechanism
<--------> <------------------------->
Figure 2 User-End ANCP Framework
Note that the Regional Network on the right-hand side has not been
drawn due to lack of space.
3.2.1. Changes to ANCP for this framework
At this stage it is difficult to be definitive in the changes
required in ANCP for a User-End version of ANCP. What can be
determined at this early stage are the following high-level
requirements on the portability of the implementations.
o By their very nature, the routers that would need to implement
ANCP at the user end would be smaller, have lower CPU capacity and
memory footprint than any NAS router. This is offset by the fact
that in many cases they are supporting a far lower number of users
per ANCP instance.
Floreani and Wood Expires December 27, 2007 [Page 7]
Extension of ANCP for Satellite and Terrestrial Modem Networks June 2007
o It is unlikely in many instances that a policy server equivalent
to the one specified to support the NAS router will be present.
So the User-End ANCP may need to work with a predefined number of
policies configured in the router.
3.3. Framework for User-End ANCP in a point-to-point topology
The natural evolution of the creation of a User-End ANCP feature is
the ability to run two satellite modems back-to-back, allowing the
User-End ANCP to run independently, with each end controlling the
outbound traffic between CPE router (RTR) and Satellite Modem (SM).
User-End Access Node
Control Mechanism
<-------->
+-----+ +-----+ +-----+
| RTR |-| SM |---| |-- - -
+-----+ +-----+ | |
| SAT |
+-----+ +-----+ |(RF) |
| RTR |-| SM |---| |-- - -
+-----+ +-----+ +-----+
User-End Access Node
Control Mechanism
<-------->
Figure 3 Point-to-Point User-End ANCP Framework
In this case, the Policy Server component resides within the CPE
router, in the form of policy lists that the router chooses between,
depending on variables supplied by the ANCP process.
Again it is important to note that in Figure 3, it is just as
feasible to have terrestrial radios in the place of the satellite
modems and satellite repeater.
3.4. Framework for Bidirectional User-End ANCP
In some cases, there may be a requirement for knowledge of the
incoming rates from the modem. This would be particularly important
if the information is required for call admission control for e.g.
Voice over IP, further up the protocol stack. This is applicable to
both the User-End ANCP frameworks mentioned above, i.e. both point-
to-point and hub-spoke scenarios.
Floreani and Wood Expires December 27, 2007 [Page 8]
Extension of ANCP for Satellite and Terrestrial Modem Networks June 2007
There are two approaches to solving this problem. Either another
protocol is created to allow instances of ANCP in the RTR and NAS to
share information (or between RTR instances in the point-to-point
case). Alternatively, ANCP instances in the satellite modem and
satellite hub can send simultaneous information updates to both the
RTR and NAS device.
Note that control requests from the router to the modem are probably
not required, as there is little that a router needs to configure on
the input as far as traffic shaping is concerned. However, if a
router is provisioned with different differentiated services code
points (DSCP), it may be helpful to pass the mapping of those
codepoints, and how to treat packets using them, down to the modem.
Consideration of DSCP control requests is outside the scope of this
document.
+--------+
| Policy |
Hub-Spoke Example | Server |
+--------+
|
+-----+ +-----+ +-----+ +--------+ +-----+
| RTR |-| SM |---| |---| | | |
+-----+ +-----+ | | | SAT | +---------+ | |
| SAT | | HUB |---| Aggreg. |---| NAS |---
+-----+ +-----+ | | | | | Node | | |
| RTR |-| SM |---| |---| | +---------+ | |
+-----+ +-----+ +-----+ +--------+ +-----+
User-End
<-- Information Reports --------------------------------->
Hub-End
<------------------------------- Information Reports ---->
Point-to-Point Example
+-----+ +-----+ +-----+ +-----+ +-----+
| RTR |-| SM |---| SAT |---| SM |-| RTR |
+-----+ +-----+ +-----+ +-----+ +-----+
<-- Information Reports ------------>
<------------ Information Reports -->
Figure 4 Bidirectional Information Reports
Floreani and Wood Expires December 27, 2007 [Page 9]
Extension of ANCP for Satellite and Terrestrial Modem Networks June 2007
4. Security Considerations
At this stage we do not see any extra security issues over and above
the existing use of ANCP.
5. IANA Considerations
No IANA considerations have been raised at this time.
6. Conclusions
This document outlines how the use of ANCP can be extended over and
above its initial deployment, namely into the satellite and
terrestrial wireless modem markets. There are varying degrees to
which ANCP can be used within these markets. The satellite hub-and-
spoke topology is similar to the DSL hub-and-modem topology, so it is
a natural fit with ANCP, and we believe that ANCP could be adopted
for satellite ISPs quite easily.
Modifications to how ANCP is deployed would also allow it to be used
in the satellite and terrestrial point-to-point markets, solving the
ongoing issue of how to traffic shape-services when passing over
dynamic modem links that vary in offered speed.
7. Acknowledgments
The authors thank Wojciech Dec for advice on ANCP during the
formulation of the above ideas.
Floreani and Wood Expires December 27, 2007 [Page 10]
Extension of ANCP for Satellite and Terrestrial Modem Networks June 2007
8. References
[1] Ooge, S., et al., "Framework and Requirements for an Access
Node Control Mechanism," work in progress as an internet-draft,
draft-ietf-ancp-framework-01.txt, Feb 13, 2007.
[2] Wadhwa, S., et al., "Protocol for Access Node Control Mechanism
in Broadband Networks," work in progress as an internet-draft,
draft-ietf-ancp-protocol-00.txt, Feb 25, 2007.
Authors' Addresses
Daniel Floreani
Cisco Systems
91 King William Street
Adelaide
South Australia
Phone: +61-8-8124-2206
Email: danielf@cisco.com
Lloyd Wood
Cisco Systems
11 New Square Park
Bedfont Lakes
Feltham TW14 8HA
England
United Kingdom
Phone: +44-20-8824-4236
Email: lwood@cisco.com
Floreani and Wood Expires December 27, 2007 [Page 11]
Extension of ANCP for Satellite and Terrestrial Modem Networks June 2007
Intellectual Property Statement
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.
Disclaimer of Validity
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.
Copyright Statement
Copyright (C) The IETF Trust (2007).
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.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Floreani and Wood Expires December 27, 2007 [Page 12]
