Network Working Group P. Tsuchiya INTERNET-DRAFT Bellcore Z. Wang University College London November 1992 IPv7 Criteria Analysis for EIPIP Status of this Memo This document is 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. Internet Drafts may be updated, replaced, or obsoleted by other documents at any time. It is not appropriate to use Internet Drafts as reference material or to cite them other than as a "working draft" or "work in progress." Please check the I-D abstract listing contained in each Internet Draft directory to learn the current status of this or any other Internet Draft. Abstract This document describes how the IPv7 proposal called EIPIP (Extended IP using PIP) meets the evaluation criteria established by the Internet Engineering Steering Group and described in "RFC-1380 IESG Deliberations on Routing and Addressing". EIPIP is currently developed to be both a transition mechanism for a new IP protocol (PIP), and the new IP protocol. This document also includes how EIPIP meets the criteria described by Partridge/Kastenholz in their internet draft [9]. Acknowledgements This document is based on the work of the PIP Working Group of the Internet Engineering Task Force. PIP WG, Expires May. 1, 1993 [Page 1] INTERNET-DRAFT PIP IPv7 Criteria Analysis November 1992 The authors would like to mention that much of the text for this internet draft was taken straight out of the IPv7 criteria analysis for IPAE/SIP [10]. This was for reasons of reducing the work load on the authors, and was possible because of the many parallels between this work and the IPAE/SIP work. 1. INTRODUCTION The `P' Internet Protocol was developed as a next generation internet protocol [1,2,3,6,7], providing the basis for new features such as policy routing and flow, and providing mechanisms for easy evolution to new features. EIP (Extended IP) [4] was developed to be a mechan- ism for easy transition to a new internet protocol EIPIP is the use of EIP as the transition mechanism for PIP [5]. This document describes how EIPIP meets the analysis criteria esta- blished by the Internet Engineering Steering Group and described in "RFC-1380 IESG Deliberations on Routing and Addressing" [8]. This document pertains to the "near-term" version of EIPIP--what is called "Basic PIP" in [1] and [2]. This is the use of EIPIP with simple hierarchical addresses--roughly the same capability that SIP and CLNP provide, with the notable exception that EIPIP provides a means of hiding inter-domain addressing conventions from intra-domain routers and hosts, thus solving the problems brought about by provider-based hierarchical addressing. The features that will evolve with PIP--for instance, flow and policy-based routing, do not pertain to this evaluation. This document also includes how EIPIP meets the criteria described by Craig Partridge and Frank Kastenholz [9]. The following definitions apply to the remainder of the document. An IPv4 host implements only IPv4. A EIPIP host implements IPv4 and EIPIP. 1.1. CAVEATS While much work has been done on PIP/EIPIP, work remains to be done. The authors believe that this statement can be made about all of the PIP WG, Expires May. 1, 1993 [Page 2] INTERNET-DRAFT PIP IPv7 Criteria Analysis November 1992 proposals, but to be fair, more work remains to be done on EIPIP than the other proposals. This is because EIPIP takes the internet well beyond what the other proposals do. The other proposals pretty much maintain the status quo of IP, except that the scaling and address depletion problems are solved (though at the same time, other prob- lems, such as how to form hierarchical addresses, arise). EIPIP is designed to evolve the internet into the foreseeable future. Where appropriate, this analysis will indicate where documentation for claimed capabilities is still missing. The second caveat is to point out that, it total, three transition schemes and three new protocols are being proposed. The three tran- sition schemes are 1) IPAE, 2) EIP, and 3) a new internet protocol header. The three new protocols are 1) SIP, 2) PIP, and 3) CLNP. It so happens that the three transition schemes and three new internet protocols are paired as numbered above. The transitions schemes are, however, orthogonal to the three new internet protocols. There is no reason that SIP, PIP, or CLNP can't be combined with any of the three transition schemes. Thus, anything written about IPAE or transition to a new internet header, for instance, can be equally applied to PIP. 2. IESG EVALUATION CRITERIA This section describes how IPAE and SIP meet the IESG criteria. The IESG criteria are delineated by ">>". 2.1. DESCRIPTION OF THE PROPOSED SCHEME >> B.1 Description of the Proposed Scheme >> >> A complete description of the proposed routing and addressing >> architecture should be supplied. This should be at the level of >> detail where the functionality and complexity of the scheme can be >> clearly understood. It should describe how the proposal solves the >> basic problems of IP address exhaustion and router resource overload. EIPIP is described in detail in the following documents currently PIP WG, Expires May. 1, 1993 [Page 3] INTERNET-DRAFT PIP IPv7 Criteria Analysis November 1992 published as Internet Drafts: The 'P' Internet Protocol [1] PIP Overview and Examples [2] PIP Header Processing [3] EIP: The Extended Internet Protocol - a framework for maintaining backward compatibility [4] The EIPIP Protocol: a PIP engine with an EIP shell [5] PIP Objects [6] PIP Identification [7] In summary the EIPIP proposal uses IP options and translation between IPv4 and EIPIP to transition to EIPIP. It can be first deployed in existing border routers to solve the current routing explosion prob- lems and later deployed in hosts to solve the IP network address exhaustion problem. 2.2. CHANGES REQUIRED >> All changes to existing protocols should be documented and new >> protocols which need to be developed and/or deployed should be >> specified and described. This should enumerate all protocols which >> are not currently in widespread operational deployment in the >> Internet. >> Changes should also be grouped by the devices and/or functions they >> affect. This should include at least the following: >> - Protocol changes in hosts >> - Protocol changes in exterior router >> - Protocol changes in interior router >> - Security and Authentication Changes >> - Domain name system changes >> - Network management changes >> - Changes required to operations tools (e.g., ping, trace- >> route, etc) - Changes to operational and administration PIP WG, Expires May. 1, 1993 [Page 4] INTERNET-DRAFT PIP IPv7 Criteria Analysis November 1992 >> procedures >> The changes should also include if hosts and routers have their >> current IP addresses changed. >> The impact and changes to the existing set of TCP/IP protocols should >> be described. This should include at a minimum: >> - IP >> - ICMP >> - DNS >> - ARP/RARP >> - TCP >> - UDP >> - FTP >> - RPC >> - SNMP >> The impact on protocols which use IP addresses as data should be >> specifically addressed. The EIPIP proposal introduces a new packet format, EIPIP, at the Internet layer. However, this format is recognizable by IPv4 sys- tems, because the PIP part is formatted as an IP option. It will simply be treated as an unknown option by IPv4 systems. This greatly eases transition. In the near term, Basic EIPIP Hosts will be able to form EIPIP headers from DNS answers. In the long term, however, an EIPIP Header Server will be developed to simplify host header processing and to handle policy routing. The Header Server will be positioned between DNS and the EIPIP Host. It will be able to take a DNS query from an EIPIP Host, forward it to DNS, receive the DNS answer, and format an EIPIP header that the EIPIP Host can use. The purpose of this box is to provide a means of "spoonfeeding" EIPIP hosts EIPIP headers as features such as policy routing are added to the internet. This will greatly simplify evolution of the internet. Note that such a box is not very useful with CLNP or SIP because these protocols provide no basis for evolution of new features. Finally, EIPIP requires a few new ICMP-type error messages (for instance, to indicate that the ID and RD (Routing Directive) fields PIP WG, Expires May. 1, 1993 [Page 5] INTERNET-DRAFT PIP IPv7 Criteria Analysis November 1992 do not represent the same system, or to indicate that the HD or RC used is not current). No other new protocols are required. The transition to EIPIP is described in detail in [4] and [5]. Because both EIP and IPAE retain a valid IP header, transition with EIP is similar to transition with IPAE, with the exceptions that with transition to EIP, 1) no modifications to ICMP are required, 2) back- bone routers as well as border routers must be modified (note that virtually all backbone routers are also border routers), and 3) translation from EIP back to IP is not necessary except in the cases where either a) internal routers and hosts cannot handle unknown options, or b) the packet header exceeds 60 bytes. A major difference between "Basic PIP" and SIP is that PIP carries hierarchical addresses in a new form--a chain of individual values rather than a single value. Thus, routing algorithms that previously carried mask/address information must be modified to carry hierarchi- cal level/value information. The semantics of the two types of information are the same, however, so the extra changes to the rout- ing protocols are minimal. Another difference between Basic PIP and SIP is that PIP neighbor systems require knowledge of each other's Handing Directive (HD) and Routing Context (RC) mappings [6]. Thus, "neighbor configuration" algorithms such as routing and router discovery must be modified to convey these mappings. This extra complexity of course returns tan- gible benefits--a general tagging capability and easier evolution. Except for these differences, the "CHANGES REQUIRED" section in [10] applies to this analysis. 2.3. IMPLEMENTATION EXPERIENCE >> B.3 Implementation Experience >> >> A description of implementation experience with the proposal should be >> supplied. This should include the how much of the proposal was >> implemented and hard it was to implement. If it was implemented by >> modifying existing code, the extent of the modifications should be PIP WG, Expires May. 1, 1993 [Page 6] INTERNET-DRAFT PIP IPv7 Criteria Analysis November 1992 >> described. Current implementation experience with EIPIP is described in [5]. This experience is minimal, and should be viewed more as a "good faith" effort to show progress by November rather than a meaningful implementation experience. So far, the following has been implemented: 1. An EIPIP host that can create EIPIP headers from the IP addresses returned by DNS. The PIP address is formed by simply taking the network number and placing it in an FTIF (Forwarding Table Index Field) of the Routing Directive (RD). Therefore, the PIP address has the same semantics as an IP address. (Future EIPIP Hosts will of course create a larger address.) 2. An EIPIP router that can forward the packets created by the EIPIP host. 3. A more general EIPIP router, but the code is not yet working. 4. A preliminary version of the EIPIP Header Server box. This code has also not yet been tested. 5. A version of TCP Dump that can parse and display all of the fields of the EIPIP header. Using the EIPIP Host and matching router, EIPIP packets have been successfully transmitted to IPv4 hosts all over the internet. 2.4. LARGE INTERNET SUPPORT >> B.4 >> >> The proposal should describe how it will scale to support a large >> internet of 10^^9 networks. It should describe how the proposed >> routing and addressing architecture will work to support an internet >> of this size. This should include, as appropriate, a description of >> the routing hierarchy, how the routing and addressing will be >> organized, how different layers of the routing interact (e.g., >> interior and exterior, or L1, L2, L3, etc), and relationship between PIP WG, Expires May. 1, 1993 [Page 7] INTERNET-DRAFT PIP IPv7 Criteria Analysis November 1992 >> addressing and routing. >> >> The addressing proposed should include a description of how addresses >> will be assigned, who owns the addresses (e.g. user or service >> provider), and whether there are restrictions in address assignment or >> topology. PIP addresses are variable in length and variable in the number of hierarchy levels they can have. PIP addresses are formed differently from either SIP or CLNP addresses. Rather than a maskable string, PIP addresses consist of a series of values, each one representing one layer of the hierarchy. This form of address allows considerable flexibility to the address assignment process. First, it allows each "address assignment authority" complete flexibility in handing out numbers to the lower layers, without having to worry about the amount of field space provided. Second, it allows hierarchy layers to be added to the address without any impact on the layers above the added layer. Semantically, the PIP address is equivalent to any mask-based hierarchical address, and therefore has the scaling characteristics of any mask-based hierarchical address. Scaling to 10**9 networks simply requires that there be enough levels of hierarchy in the address. PIP proposes the use of provider-based addresses (though, geographical-based addresses can be used with PIP if desired). Provider-based addresses scale better than geographical-based addresses because each provider only need keep track of it's own sub- scribers, rather than other provider's subscribers as is necessary with geographical-based addresses. The traditional problem with provider-based addresses is the diffi- culty of dealing with 1) multiple providers, and 2) changing provid- ers. PIP solves this problem by isolating external addressing con- ventions from internal addressing conventions. Because the PIP address is conveyed as a series of values, only those values required for a given packet need be put in the EIPIP header. For instance, if two hosts are in the same level 1 area, they do not need to include any part of the PIP address representing level 2 and up. Thus, no intra-domain packet need contain any inter-domain "address prefix" (not strictly a prefix with PIP, but the word prefix conveys the intent). Further, because of the forwarding rules of EIPIP, the inter-domain PIP WG, Expires May. 1, 1993 [Page 8] INTERNET-DRAFT PIP IPv7 Criteria Analysis November 1992 parts of the PIP address can be written into the PIP header as the EIPIP packet exits the domain. And, EIPIP Hosts identify the source and destination of EIPIP packets using the ID fields, not the PIP address. Therefore, internal routers and hosts need have no knowledge of external addressing information. In other words, a domain can be attached to multiple providers, and can change provid- ers, without any impact on internal hosts and routers (only DNS and border routers must be reconfigured). Routing of EIPIP packets is performed in the same way, and using the same routing protocols, as contemporary IPv4 or CLNP, modified as necessary to handle level/value pairs instead of mask/address pairs. The approach is the same as that proposed for CLNP/TUBA, using a variety of routing protocols (e.g., OSPF, BGP, IDRP), composed hierarchically according to the addressing hierarchy. Regarding assignment and ownership of PIP addresses: An address authority, such as ISOC or IANA, assigns top-level numbers (with an unlimited range). These numbers are assigned to providers and to countries. The countries are free to assign top-level - 1 numbers to providers in their countries. Providers assign numbers at the next level down to their subscribers. Subscribers can assign numbers at the next level down as they see fit, and so on. At the bottom level (host, or sub-host) 32 bit numbers are assigned. These are the numbers that appear in what is currently the source and des- tination IP address. During the transition period, these numbers will conform to IP address assignment conventions. At no point does an address authority have to make a decision about how much address space is allocated to the next level down, because all levels come out of a virtually unlimited number space. The size of the fields in the EIPIP header is dynamically determined at packet creation time based on a simple algorithm. 2.5. SYNTAX AND SEMANTICS OF NAMES, IDENTIFIERS AND ADDRESSES >> B.5 Syntax and semantics of names, identifiers and addresses >> >> Proposals should address the manner in which data sources and >> sinks are identified and addressed, describe how current domain >> names and IP addresses would be used/translated/mapped in their PIP WG, Expires May. 1, 1993 [Page 9] INTERNET-DRAFT PIP IPv7 Criteria Analysis November 1992 >> scheme, how proposed new identifier and address fields and >> semantics are used, and should describe the issues involved in >> administration of these id and address spaces according to their >> proposal. The deployment plan should address how these new >> semantics would be introduced and backward compatibility >> maintained. >> >> Any overlays in the syntax of these protocol structures should be >> clearly identified and conflicts resulting from syntactic overlay >> of functionality should be clearly addressed in the discussion of >> the impact on administrative assignment. Data sources and sinks are identified by their Domain Names and their PIP IDs. The Domain Names are identical to those currently used. The Domain Names and PIP IDs are associated with one or more PIP addresses. Initially this association will be done via DNS, but later may be done by other means, such as a protocol to track mobile hosts. The PIP IDs can be an extension of the current IP address, or they can be unrelated [7]. PIP IDs are 64 bits in length, and are described in detail in [7]. The lowest level of the PIP address is a full 32-bit number. During transition, this number will be a unique IP address. After transi- tion, it will only be guaranteed to be unique among systems that have higher layers of the address in common. These IP addresses will pro- vide global backwards compatibility during transition, and local (intra-domain) backwards compatibility after transition. During transition, this number can be mapped into a full PIP address by border routers. Towards this end, border routers will have rela- tively static translation tables. These tables will be updated periodically (nightly or weekly) using SNMP. The semantics of the Domain Name are as currently used. The seman- tics of the PIP address is as routing information only. In other words, it is just used to get a packet to its destination. Hosts use the PIP ID to determine sources and sinks of EIPIP packets. 2.6. PERFORMANCE IMPACT >> B.6 Performance Impact PIP WG, Expires May. 1, 1993 [Page 10] INTERNET-DRAFT PIP IPv7 Criteria Analysis November 1992 >> >> The performance impact of the new routing and addressing architecture >> should be evaluated. It should be compared against the current state >> of the art with the current IP. The performance evaluation for >> routers and hosts should include packets-per-second and memory usage >> projections, and bandwidth usage for networks. Performance should be >> evaluated for both high speed speed and low speed lines. >> >> Performance for routers (table size and computational load) and >> network bandwidth consumption should be projected based on the >> following projected data points: >> >> -Domains 10^^3 10^^4 10^^5 10^^6 10^^7 10^^8 >> -Networks 10^^4 10^^5 10^^6 10^^7 10^^8 10^^9 >> -Hosts 10^^6 10^^7 10^^8 10^^9 10^^10 10^^11 Until we have significant implementation experience, it is difficult to give hard numbers for performance. However, the following points can be made: 1. The EIPIP header is 13 32-bit words in length plus the FTIFs, which constitute the address. For provider-based addresses with one more hierarchy level than IP, the FTIFs will be 3 words, for a total of 16 words. This is substantially longer than IP (which is 5 words). Therefore, some kind of header compression (not yet specified) will be required for slow links. 2. EIPIP header processing, not including the address lookup, requires more work than IP. On one hand, there is no checksum to recalculate. On the other hand, the HD and RC must be modi- fied on transit. Each modification will be a write from one memory location (that holding forwarding information) to another (that holding the packet). The cost of this is higher on multi- cast packets, where the HD and RC must be modified differently on each outgoing packet. 3. EIPIP routing table lookup will often require less work than IP (or SIP or CLNP). This is because the a tree lookup for a masked address can be very expensive. EIPIP lookups always occur on flat values (a single FTIF), and therefore tree-based lookups are not necessary. PIP WG, Expires May. 1, 1993 [Page 11] INTERNET-DRAFT PIP IPv7 Criteria Analysis November 1992 2.7. SUPPORT FOR TCP/IP HOSTS THAN DO NOT SUPPORT THE NEW ARCHITECTURE >> B.7 Support for TCP/IP hosts than do not support the new architecture >> >> The proposal should describe how hosts which do not support the new >> architecture will be supported -- whether they receive full services >> and can communicate with the whole Internet, or if they will receive >> limited services. Also, describe if a translation service be provided >> between old and new hosts? If so, where will be this be done. For the transition period when IPv4 addresses are still globally unique (i.e. before the Internet runs out of IP network addresses) EIPIP provides direct communication between IPv4 and EIPIP hosts. All hosts will be able to communicate to all other hosts regardless of which protocol they implement. Translation service will be done in border routers. Similarity between EIPIP and IP makes translation straightforward. After IP network addresses have run out, EIPIP will permit IPv4 hosts to communicate with EIPIP hosts with in a site. 2.8. EFFECT ON USER COMMUNITY >> B.8 Effect on User Community >> >> The large and growing installed base of IP systems comprises people, >> as well as software and machines. The proposal should describe >> changes in understanding and procedures that are used by the people >> involved in internetworking. This should include new and/or changes >> in concepts, terminology, and organization. It is expected that the impact on the user community (to the extent that one can quantify such things) will be substantial. EIPIP is a new approach to internetworking--addresses look different (even if semantically they behave the same), IDs are introduced, routers can tag packets, the contents of the HD and RC fields can change hop by hop even when the semantics are the same, and it is expected that policy routing will be used quite soon after the introduction of EIPIP (because the use of limited policy routing, for instance back- bone selection, is so straightforward). PIP WG, Expires May. 1, 1993 [Page 12] INTERNET-DRAFT PIP IPv7 Criteria Analysis November 1992 However, if the internet is eventually going to evolve to new features such as flow and policy routing, then this re-education must happen sooner or later. SIP and CLNP represent a small re-education now but more re-education later. Perhaps EIPIP in the *long term* represents the least impact on the user community! 2.9. DEPLOYMENT PLAN DESCRIPTION >> B.9 Deployment Plan Description >> >> The proposal should include a deployment plan. It should include the >> steps required to deploy it. Each step should include the devices and >> protocols which are required to change and what benefits are derived >> at each step. This should also include at each step if hosts and >> routers are required to run the current and proposed internet >> protocol. >> >> A schedule should be included, with justification showing that the >> schedule is realistic. The protocol and device changes required for each step are described in section 2.2 of this document. A proposed schedule for this transition plan is as follows: 1. Complete specifications and protocol changes Jul 95 2. Deploy EIPIP in Backbone Routers and Jan 96 Implement DNS Changes 3. Start EIPIP Deployment in Hosts, Jan 96 Intra-domain routers 4. IP addresses no longer unique Jan 00? 2.10. SECURITY IMPACT >> B.10 Security Impact >> >> The impact on current and future security plans should be >> addressed. Specifically do current security mechanisms such as PIP WG, Expires May. 1, 1993 [Page 13] INTERNET-DRAFT PIP IPv7 Criteria Analysis November 1992 >> address and protocol port filtering work in the same manner as >> they do today, and what is the effect on security and >> authentication schemes currently under development. For Further Study. 2.11. FUTURE EVOLUTION >> B.11 Future Evolution >> >> The proposal should describe how it lays a foundation for solving >> emerging internet problems such as security/authentication, mobility, >> resource allocation, accounting, high packet rates, etc. Future evolution is the area where EIPIP really shines. EIPIP will evolve well because 1) the EIPIP header format and forwarding rules are very general, and 2) EIPIP has explicit mechanisms to make the introduction of new features easier. Before describing EIPIP's future evolution capabilities, it is worth mentioning that all of the features described for future evolution in [10] apply to EIPIP. The EIPIP header is general in the following ways: 1. The FTIF Chain can encode hierarchical addresses, policy routes, source routes, and multi-level VCIs. These different routing and addressing paradigms can co-exist, because the RC field dis- tinguishes FTIFs from different address families. 2. The RC and HD fields can encode different qualities of service (for routing and handling respectively). 3. Both the RC and HD can be modified on transit, allowing packet tagging by routers. Packet tagging could be used to allow packet to take alternate routes (to avoid congestion), or to modify the priority of a packet, for instance. EIPIP supports transition in the following ways: PIP WG, Expires May. 1, 1993 [Page 14] INTERNET-DRAFT PIP IPv7 Criteria Analysis November 1992 1. By designing a host interface protocol that allows an EIPIP Header Server to spoonfeed the EIPIP Host the HD and RD, old EIPIP hosts can be made to transmit new types of EIPIP headers. Note that this is only possible because the host uses neither the HD nor the RD to help it identify a received packet. Thus, the HD and RD can evolve in the presence of old-style hosts. 2. Part of the Host Part of the EIPIP header is the "Host Version" field. The purpose of this field is to convey to routers how advanced the EIPIP Host is--that is, what new protocols the EIPIP Host has implemented. This field makes it easier to add new functions to EIPIP Hosts and still deal with older EIPIP Hosts. 3. A general tunneling mechanism is mandatory with EIPIP. Both hosts and routers must be able to form and parse EIPIP tunnels. Tunneling is a very powerful tool for evolving some but not all routers in an internet, because old-style routers can be tun- neled through. Tunneling is also useful for routing through transit domains without requiring that the internal routers keep external routing information. 4. The separation of HD and RC syntax and semantics is another powerful tool for evolution. Because routers and hosts use a configuration protocol to indicate the semantics of their HD and RC fields (which convey such things as QOS and address type), new HD and RC semantics can more easily be added to the internet incrementally. 5. Because the RC can identify multiple address families (and indeed is used to distinguish unicast addresses from multicast addresses), the RC can be used as a means of introducing new addressing paradigms to the internet. 3. PARTRIDGE/KASTENHOLZ CRITERIA >> 1. The protocol must allow a straightforward transition plan from >> the current IPv4. >> >> [If we can't transition to the new protocol, then no matter how wonderful >> it is, we'll never get to it.] PIP WG, Expires May. 1, 1993 [Page 15] INTERNET-DRAFT PIP IPv7 Criteria Analysis November 1992 EIPIP provides a straightforward flexible transition plan. It is first deployed in (~100) backbone routers. This provides an immedi- ate and permanent solution to the IP Routing explosion problems. The next step is to deploy EIPIP in hosts. This step does not have to be completed until the Internet approaches the time when IP Network addresses are close to running out. This should provide enough time to convert the majority of hosts in the internet. During this tran- sition period (~5 year) border routers will provide translation ser- vices between IP only and EIPIP hosts. Direct communication is only provided between EIPIP and IP hosts only during the transition between sites globally, and after IP address are no longer globally unique, inside of a site. >> 2. The protocol must scale to allow the addressing of billions of >> end-systems. >> >> [If we cannot address all hosts in some fashion, presumably we cannot >> connect them all to the network, and we cannot hope to route data to >> them.] This topic was discussed in detail in section 2.4 "LARGE INTERNET SUPPORT". >> 3. The protocol must permit the use of routing schemes which allow >> routing tables to grow at a rate much less than linearly with the >> number of constituent networks. >> >> [If we can't route then connecting all those hosts is worthless, but >> without connected hosts, there's no point in routing. Thus this is >> third.] >> >> (As a rough sanity check for any scheme, assume that an inexpensive >> router [costing $5K 1992 USD] in the year 2000 will have around 1 gigabyte >> of router table memory and at that time there will be about 2 million >> networks and 75 million end-systems). Because EIPIP uses hierarchical addressing, and because extra layers of hierarchy can be added more easily than with traditional addresses, the scaling of EIPIP is much less than linear with the number of networks. >> 4. The protocol must work across an internetwork with individual link >> speeds ranging from a few kilobits per second to hundreds of gigabits >> per second. By work, we mean we have hopes that it can come close to >> filling the link at high speeds, but scales gracefully to deal with PIP WG, Expires May. 1, 1993 [Page 16] INTERNET-DRAFT PIP IPv7 Criteria Analysis November 1992 >> low speeds. >> >> [The joy of IP is that it works over just about anything. That ease >> of adding new technologies must be maintained. I believe this range >> of speed is right for the next twenty years, though it may be we should >> say terabits at the high-end]. EIPIP is well suited to fast link speeds, because it can be switched efficiently. EIPIP has a rather large header, and may be quite inef- ficient for low speed links. In this case, some header compression algorithm must be developed. >> 5. The protocol must support an unreliable datagram delivery service. >> >> [We like IP's datagram service and it seems to work very well. So >> let's keep it. But clearly it matters less than being able to get >> the data from here to there, which points 1-4 cover]. EIPIP does. >> 6. The protocol must allow for both unicast and multicast addressing. >> >> [So far, we've done well with unicast and broadcast but broadcast >> scales far less well than multicast. We can fight about whether >> we should say "local" multicast, i.e. just on the local subnet here, >> and make wide-area multicast a lesser priority. Certainly the >> ability to send to more than one peer in a message has proved >> important. This is an enhancement to the datagram delivery service >> so it pre-supposes 5]. EIPIP supports both unicast and multicast. The RC is used to distin- guish one address type from the other. The extensions to the Inter- net Group Multicast Protocol (IGMP) to support the SIP addresses is straight forward and is limited to supporting the larger addresses. EIPIP allows multicast groups to be formed between both IP and EIPIP hosts. >> 7. The protocol must support some means for cost recovery. >> >> NOTE: this doesn't say billing. Just that commercial providers need >> to be able to puzzle out some way to charge for services. Charging >> based on leased-line rates, etc., as we do today, is OK. >> >> [If we don't have the right services, billing for them isn't useful, >> so this goes below the previous 6 points]. PIP WG, Expires May. 1, 1993 [Page 17] INTERNET-DRAFT PIP IPv7 Criteria Analysis November 1992 Cost recovery information could be placed in the HD, could be gleaned from the PIP address or the PIP ID, or could be placed in an option field. In the absence of a billing scheme, it is hard to say much else. >> 8. The protocol should support guaranteed flows. >> >> [Multimedia is on our desk top. The IETF multicast shows we can do >> it over internetworks, with some hitches. We must accept that multimedia >> is part of the networking future. If we better understood the problem, >> I'd put this about the starred line. Most folks believe that multicast >> delivery of flows is important, so it falls below multicast.] EIPIP has several means by which it can support flows. First, it is possible to assign packets to flow groups using the HD. In this case, the HD would indicate a queueing discipline, while the RD would indicate the routing. Second, the FTIFs can be used as VCIs, and can be hierarchical (in the sense of ATM VCIs) if desired. In this case, the FTIF would indicate the queueing discipline and the routing. >> 9. The protocol should support mobile hosts. >> >> [Again, mobility is becoming increasingly important. Look at the portables >> that everyone is carrying. Note the strength of the Apple commercial >> showing someone automatically connecting up her Powerbook to her computer >> back in the office. I think conferencing and multimedia support from >> your regular office computer is more important than mobility, thus >> this falls after 8]. EIPIP is compatible with the current work in mobility. The current two main approaches to mobility (loose source route and encapsula- tion) are both very compatible with EIPIP. EIPIP defines an encapsu- lation mechanism (tunneling) that uses only the HD and RD parts of the EIPIP header, thus it adds little to header size. The FTIF Chain is completely flexible with respect to forming a loose source route, and doesn't impact forwarding performance. However, EIPIP adds another solution approach to mobility, which is the use of the PIP ID to identify the mobile endpoint, while the RD is used to route to its current network address. >> 10. The protocol should permit the use of security in the network. >> >> [This is not just for the military, but for banks, etc. And note >> all the folks who want to put security in for their local installations. PIP WG, Expires May. 1, 1993 [Page 18] INTERNET-DRAFT PIP IPv7 Criteria Analysis November 1992 >> Right now, I think the market values security slightly less than >> functionality, which is why it lands here]. All of the security features available to IP are also available to EIPIP. The options in EIPIP are very well suited to the definition of new security options. It eliminates the problems with the limited length of IPv4's current option lengths. >> 11. The protocol should permit easy and largely distributed >> configuration and operation. >> >> [People complain that IP is hard to manage. We cannot plug and play. >> It would be nice to fix that problem. But I think people care more >> about the previous 10 items] Certain aspects of distributed configuration are made easier by EIPIP. For instance, because EIPIP headers have an ID, which could be factory assigned to the EIPIP host, the EIPIP host can at least identify itself when searching for an address. In general, however, we agree with the authors of [10] that this is an important area which needs additional work. >> 12. The protocol should permit policy routing. >> >> [I'm most concerned with policy routing in the form of choosing carriers. >> We'd like to do it, and it would benefit the commercial community. But >> in the scheme of things, making life easier for local installations is >> probably more important than making life easy for carriers.] EIPIP is very powerful as a mechanism for carrying policy routes. Especially choosing a local carrier is straight forward, because the FTIF used for initial routing can simply the top-level FTIF of the source address--that is, the local carrier. Adding more policy route to the FTIF Chain is straight forward, and in fact has no impact whatsoever on router operation. EIPIP FTIFs can also be used to carry a path identifier, which is the method currently in use with IDPR. 4. REFERENCES [1] P. Tsuchiya, "PIP: The 'P' Internet Protocol", Internet PIP WG, Expires May. 1, 1993 [Page 19] INTERNET-DRAFT PIP IPv7 Criteria Analysis November 1992 Draft, May 1992 [2] P. Tsuchiya, "PIP Overview and Examples", Internet Draft, June, 1992. [3] P. Tsuchiya, "PIP Header Processing", Internet Draft, Nov. 1992. [4] Z. Wang, "EIP: The Extended Internet Protocol - a framework for maintaining backward compatibility", Internet Draft, June 1992. [5] Z. Wang, P. Tsuchiya, "The EIPIP Protocol: a PIP engine with an EIP shell" Internet Draft, Oct. 1992. [6] P. Tsuchiya, "PIP Objects", Internet Draft, Nov. 1992. [7] P. Tsuchiya, "PIP Identification", Internet Draft, Nov. 1992. [8] Gross, P., Almquist, P., "RFC-1380 - IESG Deliberations on Routing and Addressing", November, 1992. [9] Partridge, C., Kastenholz, F., "Criteria for Choosing IP Version 7 (IPv7)", Internet Draft, Nov. 1992. [10] Hinden, R., Deering, S., Crocker, D., "IPv7 Criteria Analysis for IP Address Encapsulation (IPAE) and the Simple Internet Protocol (SIP)", Internet Draft, Nov 1992. PIP WG, Expires May. 1, 1993 [Page 20]