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]