idnits 2.17.1 draft-ohta-sun-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-27) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (November 1996) is 10025 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC1620' is mentioned on line 51, but not defined == Unused Reference: 'RFP1620' is defined on line 239, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'CSR1' -- Possible downref: Non-RFC (?) normative reference: ref. 'CSR2' -- Possible downref: Non-RFC (?) normative reference: ref. 'IFMP' -- Possible downref: Non-RFC (?) normative reference: ref. 'RFP1620' -- Possible downref: Non-RFC (?) normative reference: ref. 'RSVP' -- Possible downref: Non-RFC (?) normative reference: ref. 'ST2' Summary: 8 errors (**), 0 flaws (~~), 3 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET DRAFT M. Ohta 3 draft-ohta-sun-00.txt Tokyo Institute of Technology 4 November 1996 6 Simple Unified Networking 8 Status of this Memo 10 This document is an Internet-Draft. Internet-Drafts are working 11 documents of the Internet Engineering Task Force (IETF), its areas, 12 and its working groups. Note that other groups may also distribute 13 working documents as Internet-Drafts. 15 Internet-Drafts are draft documents valid for a maximum of six months 16 and may be updated, replaced, or obsoleted by other documents at any 17 time. It is inappropriate to use Internet- Drafts as reference 18 material or to cite them other than as ``work in progress.'' 20 To learn the current status of any Internet-Draft, please check the 21 ``1id-abstracts.txt'' listing contained in the Internet- Drafts 22 Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 23 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 24 ftp.isi.edu (US West Coast). 26 Abstract 28 The concept of LIS for IP over ATM causes a topology mismatch between 29 the link and the internetworking layer. While it introduces some 30 inefficiency with CATENET based operation, it is not so much a 31 problem unless we try to solve this minor problem. 33 Short-cutting attempts such as NHRP can't solve the inefficiency 34 issue at all even though, or, just because, it utterly destroys the 35 CATENET model, which resulted in inelegant modifications of existing 36 protocols, which, in turn, causes scalability problems. 38 Moreover, the creation of short-cut VCs itself suffers a scalability 39 issue. 41 But, CSRs (Cell Switching Routers), or RSVP-signaled ATM switches, 42 make it possible to have end-to-end cell-by-cell relaying over IP 43 routers. That is, there is no reason to have LISes and there is no 44 inefficiency 46 The way to go for the Internet is Simple Unified Networking with the 47 CATENET model. 49 1. Introduction 51 See RFC1620 [RFC1620]. 53 2. Inefficiency Remains 55 Consider the following configuration: 57 Ha Hb Hc Hd 59 | | | | 60 ---- | ---------- | ---------- | ---------- | ---- 61 | __|__ __|__ __|__ __|__ | 62 ( ) ( ) ( ) ( ) 63 | ( ) ( ) ( ) ( ) | 64 ( Net ) ( Net ) ( Net ) ( Net ) 65 | ( A ) ( B ) ( C ) ( D ) | 66 ( ) ( ) ( ) ( ) 67 | ( ) ( ) ( ) ( ) | 68 (_____) (_____) (_____) ( ____) 69 | | | | | | | | | | 70 --- | | -------- | | -------- | | -------- | | --- 71 | | | | | | | | 72 R1 - --- R2 --- --- R3 --- --- R4 --- --- R5 73 | | 74 ---------------- R6 --------------- R7 ---------- 75 | 76 He 78 where Nets A, B, C and D are highly logical LIS in a large shared 79 medium network. 81 For example, suppose R1 is located at Frankfurt, Ha Sunnyvale, R2 82 Montreal, R3 Memphis, R4 Kuala Lumpur, Hd San Jose, R5 Mountain View, 83 R6 Danvers, R7 Menlo Park, and He Palo Alto. 85 Then, without shortcutting, Ha and Hd may communicate hop-by-hop from 86 Sunnyvale, Montreal, Memphis, Kuala Lumpur and finally to San Jose. 87 Not an inefficient path. 89 The problem is that routing metric at the Internetworking layer does 90 not reflect the real world metric at all. 92 But, if we can somehow make use of the fact that Ha and Hd are placed 93 in a single shared medium, Ha and Hd can communicate locally within 94 Silicon Valley between Sunnyvale and San Jose. 96 That's the inefficiency issue that mechanisms in RFC 1620 wanted to 97 resolve. 99 The problem is that though the inefficiency may be removed within the 100 shared medium, it's not the only inefficiency. 102 When Ha and He communicate over a path Ha-R6-R7-He, the traffic will 103 pass from Sunnyvale, Frankfurt, Danvers, Menlo Park and finally to 104 Palo Alto, even though the path Ha-R5-R7-He exists within Silicon 105 Valley. 107 The inefficiency can be avoided by raising metric within the shared 108 medium. But, it causes other type of inefficiency. That is, the 109 shared medium will not be used for transit even though the physically 110 shortest path exists over it. 112 The problem is that routing metric at the Internetworking layer 113 within the shared media does not reflect the real world metric at 114 all. 116 When a LIS contains hosts at room 1035, Fairmont Hotel, San Jose; 117 room 1036, Fairmont Hotel, San Jose; Holidy Inn San Jose; Palo Alto; 118 Los Angels and Frankfurt; there is no meaning metric for the LIS to 119 be used outside of the LIS. 121 Also, It is obvious that no intra-shared-media protocol can solve the 122 route selection problem outside of the medium at R7. 124 That is, routing metric should be mostly proportional to the physical 125 distance. Then, the least metric path will be almost optimal. 127 It means that LISes should not be so logical and mostly contiguous. 129 As a result, the CATENET model with no extension works efficiently 130 over the shared media. 132 3. Inscalability Problems 134 3.1 RSVP Inscalability 136 As the Internet protocols are designed with the CATENET model, 137 modification to the model naturally makes some protocol not work and 138 other protocol not to scale. 140 For example, RSVP scales to the number of recipients because RESV 141 messages are merged on routers upstream toward the sender. 143 But, in a large shared medium with no intermediate entity to 144 recognize IP, merger of the RESV messages is impossible. 146 As it is essential to merge RESV at the data branch point, RESV 147 merging servers external to the shared medium does not work. 149 That is, all the RESV messages concentrate and implode at the 150 upstream most router or the sender on the shared medium, which means 151 not so many recipients can be supported. 153 Note that, in the worst case when most of the hosts in the shared 154 medium are the recipients, the amount of imploding packets is almost 155 equal to the amount of ATMARP packets for a single ATMARP server 156 receives, if the entire shared medium is served by a single ATMARP 157 server. 159 That is, on multicast-aware shared medium, it's enough to make the 160 entire medium a single subnet, maybe with SCSP. 162 3.2 VC Shortage at the Egress Router 164 It is unlikely that the Internet mostly consists of a large single 165 shared medium. 167 Thus, when hosts in a shared medium wants to communicate to the 168 Internet outside of the medium, the egress routers must be directly 169 connected to each such host through a dedicated VC. 171 But, shared medium can support only a limited number of VCs for a 172 single node. 174 On existing commercial shared medium service such as X.25 or 175 framerelay, it is typical that the number of supported VCs is less 176 than 100. 178 It is typical that ATM switches can support only several thousands of 179 VCs for each port. 181 Thus, not so many hosts can communicate with the external Internet 182 efficiently 184 Other hosts can still communicate hop-by-hop. But, as the size of the 185 shared medium glows, the efficiency as a whole approaches that of 186 hop-by-hop. 188 That is, it is necessary to make the hop-by-hop communication 189 efficient by not making LISes logical, which means that no 190 inefficiency exist to be removed by shortcutting attempt. 192 4. Cell Switching Routers 193 It seems to the Author that some people thought that cell-by-cell 194 relaying was impossible over IP routers, which, seemingly, motivated 195 them to support shortcutting over ATM shared medium. 197 While it was understandable, cell-by-cell relaying over IP routers is 198 possible. 200 The point is that it is possible to signal ATM switches with RSVP 201 [RSVP], ST2 [ST2], IFMP [IFMP] or some other IP-based signaling 202 protocol. 204 Then, switch-local traffic control module sets up the cell switching 205 fabric appropriately. 207 The ATM switch signaled by IP is, in general, called CSR (Cell 208 Switching Routers) [CSR1, CSR2]. 210 5. Conclusion. 212 RFC 1620 was wrong. 214 While it suggests several ways to have shortcuts, note that the 215 discussions in section 2 and 3 does not depend on how the shortcuts 216 are created. That is, modifications on the way to have shortcuts does 217 not affect the conclusion that they are no good. 219 It is not necessary nor possible to modify the CATENET model, the 220 architecture of the Internet, to have efficient and scalable Internet 221 to accommodate shared medium such as ATM. 223 The Simple Unified Networking with the CATENET model is the way to 224 go. 226 6. References 228 [CSR1] Hiroshi ESAKI, Ken-ichi NAGAMI, Masataka OHTA, "High Speed 229 Datagram Delivery over Internet using ATM Technology", 230 Networld+Interop '95 Engineer Conference, E12-1~E12-9, (1995). 232 [CSR2] Yukinori GOTO, Masataka OHTA, Masaki HIRABARU, "Design of 233 Internet Resource Reservation on ATM Network", Proceedings of The 234 10th International Conference on Information Networking (ICOIN-10), 235 pp.510-516, 1996. 237 [IFMP] 239 [RFP1620] 241 [RSVP] 243 [ST2] 245 7. Security Considerations 247 (to be filled) 249 8. Author's Address 251 Masataka Ohta 252 Computer Center 253 Tokyo Institute of Technology 254 2-12-1, O-okayama, Meguro-ku 255 Tokyo 152, JAPAN 257 Phone: +81-3-5734-3299 258 Fax: +81-3-5734-3415 259 EMail: mohta@necom830.hpcl.titech.ac.jp