home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / drafts / draft_ietf_i / draft-ietf-ion-intra-area-unicast-00.txt < prev    next >
Text File  |  1997-07-25  |  11KB  |  278 lines
  1. Network Working Group                                      Juha Heinanen
  2. INTERNET DRAFT                                           Telecom Finland
  3. Expires January 1998                                           July 1997
  4.  
  5.  
  6.           Intra-area IP unicast among routers over legacy ATM
  7.                <draft-ietf-ion-intra-area-unicast-00.txt>
  8.  
  9.  
  10.  
  11. Status of this Memo
  12.  
  13.    This document is an Internet-Draft.  Internet-Drafts are working
  14.    documents of the Internet Engineering Task Force (IETF), its areas,
  15.    and its working groups. Note that other groups may also distribute
  16.    working documents as Internet-Drafts.
  17.  
  18.    Internet-Drafts are draft documents valid for a maximum of six months
  19.    and may be updated, replaced, or obsoleted by other documents at any
  20.    time. It is inappropriate to use Internet-Drafts as reference
  21.    material or to cite them other than as ``work in progress.''
  22.  
  23.    To learn the current status of any Internet-Draft, please check the
  24.    ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow
  25.    Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
  26.    munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
  27.    ftp.isi.edu (US West Coast).
  28.  
  29. Abstract
  30.  
  31.    This document describes how IP unicast can be efficiently implemented
  32.    among routers belonging to the same area of a routing domain, where
  33.    the connectivity is provided by a legacy ATM network as defined by
  34.    the ATM Forum or ITU.  This proposal is designed to be complementary
  35.    to IP multicast solutions such as the one described in [1].
  36.  
  37. 1. Introduction
  38.  
  39.    This document describes how a set of routers (such as the access/edge
  40.    routers of an ISP or enterprise) connected to a legacy ATM network
  41.    can in a dynamic and plug-and-play fashion optimize ATM connections
  42.    for efficient forwarding of unicast IP packets.  The method can be
  43.    used in situations where the number of routers is so large that a
  44.    full mesh of point-to-point ATM VCs is not practical from technical
  45.    or economic reasons.  In addition, it can be applied to smaller
  46.    router networks to automate the setup of a full mesh of ATM
  47.    connectivity between the routers.
  48.  
  49.  
  50.  
  51.  
  52. Heinanen                  Intra-area IP unicast                 [Page 1]
  53.  
  54. INTERNET DRAFT                                               April, 1997
  55.  
  56.  
  57.    The set of routers must belong to the same area of a link state
  58.    routing protocol, such as OSPF or IS-IS, that floods topology and
  59.    reachability information to every router in the area.
  60.  
  61.    This proposal only deals with IP unicast, but it complements and can
  62.    be used in conjunction with IP multicast solutions such as the one
  63.    described in [1].
  64.  
  65. 2. Router configuration and behavior
  66.  
  67.    As introduced above, this document defines a method of dynamically
  68.    managing ATM connectivity among a set of routers that belong to the
  69.    same area of a routing domain, where a link state protocol, such as
  70.    OSPF or IS-IS, is used to exchange topology and reachability
  71.    information.
  72.  
  73.    Before the dynamic management of ATM VCs can begin, the routers of
  74.    the area must be manually configured to exchange routing information
  75.    among themselves.  There must thus be enough initial connectivity so
  76.    that at least one IP path exists from each router to each other
  77.    router in the area.  This initial connectivity is also used to
  78.    forward IP packets when dynamic ATM VCs don't exist.
  79.  
  80.    Note that the initial connectivity doesn't necessarily need to be
  81.    implemented over ATM and that not all routers of the area need to be
  82.    ATM attached.  Furthermore, even if a router is ATM attached, it
  83.    doesn't need to participate in the dynamic management of ATM VCs.
  84.    The ATM routers of an area can thus be upgraded one at a time to
  85.    support the method described in this document.
  86.  
  87.    Once an ATM attached router R becomes operational, it may start to
  88.    measure, how many bytes it has received during the past M seconds,
  89.    whose final hop router S within the area is also ATM attached.  If
  90.    the number of bytes is less than N, R forwards the packets according
  91.    to its routing table.  When the number of bytes equals or exceeds N,
  92.    and R doesn't yet have a dynamic ATM VC to S, R creates such a VC and
  93.    starts to forward S bound packets directly.
  94.  
  95.    The dynamic ATM VC is unidirectional that allows R to manage it
  96.    autonomously without coordination with S.  Also, in order to keep the
  97.    number of routing peers small and in order to avoid frequent changes
  98.    in topology information, R doesn't use the dynamic ATM VC for the
  99.    exchange of routing information nor does R advertise the dynamic ATM
  100.    VC to its routing peers.
  101.  
  102.    ATM traffic categories and traffic parameters of the dynamic VCs are
  103.    decided locally by the network administrator.  The default traffic
  104.    category is UBR with the peak cell rate set to the link rate and the
  105.  
  106.  
  107.  
  108. Heinanen                  Intra-area IP unicast                 [Page 2]
  109.  
  110. INTERNET DRAFT                                               April, 1997
  111.  
  112.  
  113.    minimal acceptable cell rate set to zero.  Since the dynamic ATM VCs
  114.    are only used to carry IP packets, it is recommended that the packets
  115.    are "VC multiplexed" [2] to the AAL 5 payload without an LLC/SNAP
  116.    header.  See [3] and Appendix D.3.2 of [4] for details on coding of
  117.    the signalling messages.
  118.  
  119.    Once the dynamic ATM VC from R to S has been created, R starts to
  120.    measure the traffic along it.  When R detects that during the past K
  121.    seconds the number of bytes along the dynamic ATM VC to S has fallen
  122.    below L, it deletes the dynamic ATM VC and returns to the initial
  123.    mode of operation that was described above.
  124.  
  125.    The values of the constants K, L, M, and N control the rate of
  126.    dynamic ATM VC creation and deletion.  They are assigned by the
  127.    network administrator and may differ from one ATM attached router to
  128.    another.
  129.  
  130.    Setting the VC creation and deletion limits N and L to zero, turns
  131.    off the measurement process and causes the router to create a dynamic
  132.    VC to every other participating router.  That can be the default in
  133.    small router networks that want to use this method automate the setup
  134.    of a full mesh of ATM VCs.
  135.  
  136.    If a router doesn't want to set up any dynamic ATM VCs, the VC
  137.    creation limit N is set to a positive value and the measurement
  138.    interval M is set to zero.  Finally, if a router doesn't want to be a
  139.    destination of dynamic ATM VCs, it doesn't make its ATM address
  140.    available to the other routers for the purpose of this application.
  141.  
  142.    Note that if a router is not capable in measuring traffic, it can
  143.    still participate as a destination of dynamic ATM VCs and can itself
  144.    set up dynamic VCs non-selectively to every other router.
  145.  
  146. 3. Address resolution
  147.  
  148.    Since all the routers belong to the same area of a link state routing
  149.    domain, they learn each others' router IDs and the IP address
  150.    prefixes that are reachable via each router.  In order to dynamically
  151.    create an ATM VC from one router to another, the source router also
  152.    needs to learn the ATM address of the destination router.
  153.  
  154.    A router that wants to participate as a source in the dynamic
  155.    management of ATM VCs, makes its ATM address known to the other
  156.    routers of the area by including in its link state advertisements a
  157.    field that contains an ATM address of the advertising router.  In
  158.    OSPF, this ATM address information is carried in an Address
  159.    Resolution Advertizement [5] with area-local flooding scope and with
  160.    a service type.  The service type identifies the possible uses of the
  161.  
  162.  
  163.  
  164. Heinanen                  Intra-area IP unicast                 [Page 3]
  165.  
  166. INTERNET DRAFT                                               April, 1997
  167.  
  168.  
  169.    advertised ATM address which includes the dynamic creation of ATM VCs
  170.    according the method described in this document.
  171.  
  172.    A field similar to Opaque LSA could be easily defined for IS-IS.
  173.    Futher, it could be possible to use a well-known discretionary non-
  174.    transitive attribute of BGP to carry the address resolution
  175.    information, but the use of inter-domain routing protocols is outside
  176.    the scope of this document.
  177.  
  178. 4. Discussion
  179.  
  180.    The method proposed in this document allows efficient interconnection
  181.    of a set of routers over a legacy ATM network.  After small amount of
  182.    manual configuration, the routers will automatically optimize direct
  183.    connectivity among themselves based on dynamic traffic load.  Network
  184.    administrators can control the number of ATM VCs created by the
  185.    method taking into account scalability and cost.
  186.  
  187.    The number of ATM VCs could be further reduced if legacy ATM networks
  188.    would support signalling of multipoint-to-point VCs.  The method
  189.    would also benefit from the capability to renegotiate the traffic
  190.    parameters of active ATM VCs.  Both of these capabilities are
  191.    currently under study in the ATM Forum or the ITU.
  192.  
  193. 5. Security Considerations
  194.  
  195.    Since the method described in this document allows data paths to be
  196.    established that bypass the normal hop-by-hop control path, the
  197.    location of any access filters should be decided carefully.  To
  198.    ensure proper enforcement of filter policies, filters should be moved
  199.    to the edges of an area so that they me be applied on entry or exit
  200.    from the short-cut data path.
  201.  
  202. References
  203.  
  204.    [1] Farinacci, D., Meyer, D., and Rekhter, Y., "Intra-LIS IP
  205.        multicast among routers over ATM".
  206.        draft-ietf-ion-intralis-multicast-00.txt, April 1997.
  207.  
  208.    [2] Heinanen, J., "Multiprotocol Encapsulation over ATM Adaptation
  209.        Layer 5".  RFC 1483, July 1993.
  210.  
  211.    [3] Perez, M, et al., "ATM Signalling Support for IP over ATM".  RFC
  212.        1755, February 1995.
  213.  
  214.    [4] The ATM Forum, "ATM User-Network Interface Specification Version
  215.        3.1".  September 1994.
  216.  
  217.  
  218.  
  219.  
  220. Heinanen                  Intra-area IP unicast                 [Page 4]
  221.  
  222. INTERNET DRAFT                                               April, 1997
  223.  
  224.  
  225.    [5] Coltun, R., Heinanen, J., Cai Y., "The OSPF Address Resolution
  226.        Advertisement Option". Internet Draft, August 1997.
  227.  
  228. Acknowledgements
  229.  
  230.    I would like to thank Rob Coltun and Lou Berger of Fore Systems for
  231.    their comments on earlier versions of this document.
  232.  
  233. Author Information
  234.  
  235.    Juha Heinanen
  236.    Telecom Finland
  237.    PO Box 777
  238.    33101 Tampere
  239.    Finland
  240.  
  241.    Phone +358 400 500 958
  242.    Email jh@tele.fi
  243.  
  244.  
  245.  
  246.  
  247.  
  248.  
  249.  
  250.  
  251.  
  252.  
  253.  
  254.  
  255.  
  256.  
  257.  
  258.  
  259.  
  260.  
  261.  
  262.  
  263.  
  264.  
  265.  
  266.  
  267.  
  268.  
  269.  
  270.  
  271.  
  272.  
  273.  
  274.  
  275.  
  276. Heinanen                  Intra-area IP unicast                 [Page 5]
  277.  
  278.