[Search] [txt|pdf|bibtex] [Tracker] [Email] [Nits]

Versions: 00                                                            
    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
    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-
       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
       The list of Internet-Draft Shadow Directories can be accessed at
       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
       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.
       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
       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
                                                               | Policy |
                                 Hub-Spoke Example             | Server |
         +-----+ +-----+   +-----+   +--------+                 +-----+
         | RTR |-| SM  |---|     |---|        |                 |     |
         +-----+ +-----+   |     |   |  SAT   |   +---------+   |     |
                           | SAT |   |  HUB   |---| Aggreg. |---| NAS |---
         +-----+ +-----+   |     |   |        |   |  Node   |   |     |
         | RTR |-| SM  |---|     |---|        |   +---------+   |     |
         +-----+ +-----+   +-----+   +--------+                 +-----+
            <-- Information Reports --------------------------------->
            <------------------------------- 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
       South Australia
       Phone: +61-8-8124-2206
       Email: danielf@cisco.com
       Lloyd Wood
       Cisco Systems
       11 New Square Park
       Bedfont Lakes
       Feltham TW14 8HA
       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
       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
    Disclaimer of Validity
       This document and the information contained herein are provided on an
    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.
       Funding for the RFC Editor function is currently provided by the
       Internet Society.
    Floreani and Wood     Expires December 27, 2007              [Page 12]