home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / drafts / draft_n_r / draft-ohta-sun-00.txt < prev    next >
Text File  |  1996-11-26  |  11KB  |  339 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6. INTERNET DRAFT                                                   M. Ohta
  7. draft-ohta-sun-00.txt                      Tokyo Institute of Technology
  8.                                                            November 1996
  9.  
  10.                        Simple Unified Networking
  11.  
  12. Status of this Memo
  13.  
  14.    This document is an Internet-Draft.  Internet-Drafts are working
  15.    documents of the Internet Engineering Task Force (IETF), its areas,
  16.    and its working groups.  Note that other groups may also distribute
  17.    working documents as Internet-Drafts.
  18.  
  19.    Internet-Drafts are draft documents valid for a maximum of six months
  20.    and may be updated, replaced, or obsoleted by other documents at any
  21.    time.  It is inappropriate to use Internet- Drafts as reference
  22.    material or to cite them other than as ``work in progress.''
  23.  
  24.    To learn the current status of any Internet-Draft, please check the
  25.    ``1id-abstracts.txt'' listing contained in the Internet- Drafts
  26.    Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
  27.    munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
  28.    ftp.isi.edu (US West Coast).
  29.  
  30. Abstract
  31.  
  32.    The concept of LIS for IP over ATM causes a topology mismatch between
  33.    the link and the internetworking layer. While it introduces some
  34.    inefficiency with CATENET based operation, it is not so much a
  35.    problem unless we try to solve this minor problem.
  36.  
  37.    Short-cutting attempts such as NHRP can't solve the inefficiency
  38.    issue at all even though, or, just because, it utterly destroys the
  39.    CATENET model, which resulted in inelegant modifications of existing
  40.    protocols, which, in turn, causes scalability problems.
  41.  
  42.    Moreover, the creation of short-cut VCs itself suffers a scalability
  43.    issue.
  44.  
  45.    But, CSRs (Cell Switching Routers), or RSVP-signaled ATM switches,
  46.    make it possible to have end-to-end cell-by-cell relaying over IP
  47.    routers. That is, there is no reason to have LISes and there is no
  48.    inefficiency
  49.  
  50.    The way to go for the Internet is Simple Unified Networking with the
  51.    CATENET model.
  52.  
  53.  
  54.  
  55.  
  56.  
  57. M. Ohta                 Expires on May 27, 1997                 [Page 1]
  58.  
  59. INTERNET DRAFT         Simple Unified Networking           November 1996
  60.  
  61.  
  62. 1. Introduction
  63.  
  64.    See RFC1620 [RFC1620].
  65.  
  66. 2. Inefficiency Remains
  67.  
  68.    Consider the following configuration:
  69.  
  70.               Ha           Hb           Hc           Hd
  71.  
  72.               |            |            |            |
  73.          ---- | ---------- | ---------- | ---------- | ----
  74.         |   __|__        __|__        __|__        __|__   |
  75.            (     )      (     )      (     )      (     )
  76.         |  (     )      (     )      (     )      (     )  |
  77.            ( Net )      ( Net )      ( Net )      ( Net )
  78.         |  (  A  )      (  B  )      (  C  )      (  D  )  |
  79.            (     )      (     )      (     )      (     )
  80.         |  (     )      (     )      (     )      (     )  |
  81.            (_____)      (_____)      (_____)      ( ____)
  82.         |    | |          | |          | |          | |    |
  83.          --- | | -------- | | -------- | | -------- | | ---
  84.              | |          | |          | |          | |
  85.          R1 -   --- R2 ---   --- R3 ---   --- R4 ---   --- R5
  86.          |                                                 |
  87.           ---------------- R6 --------------- R7 ----------
  88.                                               |
  89.                                               He
  90.  
  91.    where Nets A, B, C and D are highly logical LIS in a large shared
  92.    medium network.
  93.  
  94.    For example, suppose R1 is located at Frankfurt, Ha Sunnyvale, R2
  95.    Montreal, R3 Memphis, R4 Kuala Lumpur, Hd San Jose, R5 Mountain View,
  96.    R6 Danvers, R7 Menlo Park, and He Palo Alto.
  97.  
  98.    Then, without shortcutting, Ha and Hd may communicate hop-by-hop from
  99.    Sunnyvale, Montreal, Memphis, Kuala Lumpur and finally to San Jose.
  100.    Not an inefficient path.
  101.  
  102.    The problem is that routing metric at the Internetworking layer does
  103.    not reflect the real world metric at all.
  104.  
  105.    But, if we can somehow make use of the fact that Ha and Hd are placed
  106.    in a single shared medium, Ha and Hd can communicate locally within
  107.    Silicon Valley between Sunnyvale and San Jose.
  108.  
  109.    That's the inefficiency issue that mechanisms in RFC 1620 wanted to
  110.  
  111.  
  112.  
  113. M. Ohta                 Expires on May 27, 1997                 [Page 2]
  114.  
  115. INTERNET DRAFT         Simple Unified Networking           November 1996
  116.  
  117.  
  118.    resolve.
  119.  
  120.    The problem is that though the inefficiency may be removed within the
  121.    shared medium, it's not the only inefficiency.
  122.  
  123.    When Ha and He communicate over a path Ha-R6-R7-He, the traffic will
  124.    pass from Sunnyvale, Frankfurt, Danvers, Menlo Park and finally to
  125.    Palo Alto, even though the path Ha-R5-R7-He exists within Silicon
  126.    Valley.
  127.  
  128.    The inefficiency can be avoided by raising metric within the shared
  129.    medium. But, it causes other type of inefficiency. That is, the
  130.    shared medium will not be used for transit even though the physically
  131.    shortest path exists over it.
  132.  
  133.    The problem is that routing metric at the Internetworking layer
  134.    within the shared media does not reflect the real world metric at
  135.    all.
  136.  
  137.    When a LIS contains hosts at room 1035, Fairmont Hotel, San Jose;
  138.    room 1036, Fairmont Hotel, San Jose; Holidy Inn San Jose; Palo Alto;
  139.    Los Angels and Frankfurt; there is no meaning metric for the LIS to
  140.    be used outside of the LIS.
  141.  
  142.    Also, It is obvious that no intra-shared-media protocol can solve the
  143.    route selection problem outside of the medium at R7.
  144.  
  145.    That is, routing metric should be mostly proportional to the physical
  146.    distance. Then, the least metric path will be almost optimal.
  147.  
  148.    It means that LISes should not be so logical and mostly contiguous.
  149.  
  150.    As a result, the CATENET model with no extension works efficiently
  151.    over the shared media.
  152.  
  153. 3. Inscalability Problems
  154.  
  155. 3.1 RSVP Inscalability
  156.  
  157.    As the Internet protocols are designed with the CATENET model,
  158.    modification to the model naturally makes some protocol not work and
  159.    other protocol not to scale.
  160.  
  161.    For example, RSVP scales to the number of recipients because RESV
  162.    messages are merged on routers upstream toward the sender.
  163.  
  164.    But, in a large shared medium with no intermediate entity to
  165.    recognize IP, merger of the RESV messages is impossible.
  166.  
  167.  
  168.  
  169. M. Ohta                 Expires on May 27, 1997                 [Page 3]
  170.  
  171. INTERNET DRAFT         Simple Unified Networking           November 1996
  172.  
  173.  
  174.    As it is essential to merge RESV at the data branch point, RESV
  175.    merging servers external to the shared medium does not work.
  176.  
  177.    That is, all the RESV messages concentrate and implode at the
  178.    upstream most router or the sender on the shared medium, which means
  179.    not so many recipients can be supported.
  180.  
  181.    Note that, in the worst case when most of the hosts in the shared
  182.    medium are the recipients, the amount of imploding packets is almost
  183.    equal to the amount of ATMARP packets for a single ATMARP server
  184.    receives, if the entire shared medium is served by a single ATMARP
  185.    server.
  186.  
  187.    That is, on multicast-aware shared medium, it's enough to make the
  188.    entire medium a single subnet, maybe with SCSP.
  189.  
  190. 3.2 VC Shortage at the Egress Router
  191.  
  192.    It is unlikely that the Internet mostly consists of a large single
  193.    shared medium.
  194.  
  195.    Thus, when hosts in a shared medium wants to communicate to the
  196.    Internet outside of the medium, the egress routers must be directly
  197.    connected to each such host through a dedicated VC.
  198.  
  199.    But, shared medium can support only a limited number of VCs for a
  200.    single node.
  201.  
  202.    On existing commercial shared medium service such as X.25 or
  203.    framerelay, it is typical that the number of supported VCs is less
  204.    than 100.
  205.  
  206.    It is typical that ATM switches can support only several thousands of
  207.    VCs for each port.
  208.  
  209.    Thus, not so many hosts can communicate with the external Internet
  210.    efficiently
  211.  
  212.    Other hosts can still communicate hop-by-hop. But, as the size of the
  213.    shared medium glows, the efficiency as a whole approaches that of
  214.    hop-by-hop.
  215.  
  216.    That is, it is necessary to make the hop-by-hop communication
  217.    efficient by not making LISes logical, which means that no
  218.    inefficiency exist to be removed by shortcutting attempt.
  219.  
  220. 4. Cell Switching Routers
  221.  
  222.  
  223.  
  224.  
  225. M. Ohta                 Expires on May 27, 1997                 [Page 4]
  226.  
  227. INTERNET DRAFT         Simple Unified Networking           November 1996
  228.  
  229.  
  230.    It seems to the Author that some people thought that cell-by-cell
  231.    relaying was impossible over IP routers, which, seemingly, motivated
  232.    them to support shortcutting over ATM shared medium.
  233.  
  234.    While it was understandable, cell-by-cell relaying over IP routers is
  235.    possible.
  236.  
  237.    The point is that it is possible to signal ATM switches with RSVP
  238.    [RSVP], ST2 [ST2], IFMP [IFMP] or some other IP-based signaling
  239.    protocol.
  240.  
  241.    Then, switch-local traffic control module sets up the cell switching
  242.    fabric appropriately.
  243.  
  244.    The ATM switch signaled by IP is, in general, called CSR (Cell
  245.    Switching Routers) [CSR1, CSR2].
  246.  
  247. 5. Conclusion.
  248.  
  249.    RFC 1620 was wrong.
  250.  
  251.    While it suggests several ways to have shortcuts, note that the
  252.    discussions in section 2 and 3 does not depend on how the shortcuts
  253.    are created. That is, modifications on the way to have shortcuts does
  254.    not affect the conclusion that they are no good.
  255.  
  256.    It is not necessary nor possible to modify the CATENET model, the
  257.    architecture of the Internet, to have efficient and scalable Internet
  258.    to accommodate shared medium such as ATM.
  259.  
  260.    The Simple Unified Networking with the CATENET model is the way to
  261.    go.
  262.  
  263. 6. References
  264.  
  265.    [CSR1] Hiroshi ESAKI, Ken-ichi NAGAMI, Masataka OHTA, "High Speed
  266.    Datagram Delivery over Internet using ATM Technology",
  267.    Networld+Interop '95 Engineer Conference,  E12-1~E12-9,  (1995).
  268.  
  269.    [CSR2] Yukinori GOTO, Masataka OHTA, Masaki HIRABARU, "Design of
  270.    Internet Resource Reservation on ATM Network", Proceedings of The
  271.    10th International Conference on Information Networking (ICOIN-10),
  272.    pp.510-516, 1996.
  273.  
  274.    [IFMP]
  275.  
  276.    [RFP1620]
  277.  
  278.  
  279.  
  280.  
  281. M. Ohta                 Expires on May 27, 1997                 [Page 5]
  282.  
  283. INTERNET DRAFT         Simple Unified Networking           November 1996
  284.  
  285.  
  286.    [RSVP]
  287.  
  288.    [ST2]
  289.  
  290. 7. Security Considerations
  291.  
  292.    (to be filled)
  293.  
  294. 8. Author's Address
  295.  
  296.    Masataka Ohta
  297.    Computer Center
  298.    Tokyo Institute of Technology
  299.    2-12-1, O-okayama, Meguro-ku
  300.    Tokyo 152, JAPAN
  301.  
  302.    Phone: +81-3-5734-3299
  303.    Fax: +81-3-5734-3415
  304.    EMail: mohta@necom830.hpcl.titech.ac.jp
  305.  
  306.  
  307.  
  308.  
  309.  
  310.  
  311.  
  312.  
  313.  
  314.  
  315.  
  316.  
  317.  
  318.  
  319.  
  320.  
  321.  
  322.  
  323.  
  324.  
  325.  
  326.  
  327.  
  328.  
  329.  
  330.  
  331.  
  332.  
  333.  
  334.  
  335.  
  336.  
  337. M. Ohta                 Expires on May 27, 1997                 [Page 6]
  338.  
  339.