Internet Draft Decao Mao Document:draft-mao-ipv4-path-routing-00.txt Insigma Techenology Expires May 22, 2005 November 22, 2004 IPv4 Path Based Routing Status of this Memo By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. 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 and may be updated, replaced, or obsolete 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 http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Copyright Notice Copyright (C) The Internet Society (2004). All Rights Reserved. Abstract This document describes a solution to the IPv4 address shortage problem. The solution is to be implemented within the IPv4 framework, rather than inside a "next generation" IP protocol. By organizing local networks as an "intranet hierarchy" attached to the Internet, nodes inside the hierarchy can be uniquely addressed with path descriptions. Two IPv4 options, Source-Side Path-info and Destination-Side Path-info, are added into the IPv4 protocol, so that up to 2 path descriptions can be carried in the IPv4 header. Further, a currently unused flag bit in the IPv4 header is used to extend the logical IPv4 header, so that options can also be carried "out-band". Core routers in the Internet will ignore the unrecognized new options and the extension, and thus need not be replaced or updated. Decao Mao Expires May 22, 2005 [Page 1] Internet Draft IPv4 Path Based Routing November 22, 2004 Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. TABLE OF CONTENTS 1. Terminologies ............................................ 2 2. Introduction ............................................. 2 3. Path description ......................................... 4 4. Path descriptions as IPv4 options ........................ 5 5. Path based routing ....................................... 6 6. Logical IPv4 header extension ............................ 8 7. Implementation and Deployment Considerations ............ 10 8. Security Considerations ................................. 11 9. IANA Considerations ..................................... 11 10. References .............................................. 11 Author's Address ............................................ 12 Intellectual Property Statement ............................. 12 Copyright Statement ......................................... 12 1. Terminologies This section presents a few terms used throughout the document. IP Address: In this document "IP Address" means 32-bit IPv4 address. Internet Address: IP address which is routable in the Internet, also called "public address" ¿C as it can be used in the "public" Internet. IP addresses other than intranet addresses are Internet addresses. It is globally unique in the entire Internet. Intranet Address: IP addresses reserved to be used in "private" networks, or "intranets". Intranet addresses are unique in the particular intranet, but not unique globally. Therefore, intranet addresses are only routable in the particular intranet, but not routable in Internet. Specifically, IP addresses in the 10.0.0.0/8, 172.16.0.0/12, and 192.168.0.0/16 ranges are intranet address. Intranet A "private" IPv4 network, where intranet addresses are used to identify the nodes and for routing. An intranet can be attached to the Internet, namely the "public" network, via an intranet gateway. 2. Introduction Many people in the Internet society believe that the key motivation behind IPv6 is the IPv4 address shortage. If this problem can be Decao Mao Expires May 22, 2005 [Page 2] Internet Draft IPv4 Path Based Routing November 22, 2004 solved within the IPv4 framework, then the deployment of IPv6 cannot be justified, since the changes are so dramatic and expensive. However, solving the problem of IPv4 address shortage within the IPv4 framework is actually possible and feasible. By organizing local networks as a hierarchy of intranet, and attaching it to the Internet via a top-level gateway, a node can be uniquely addressed with a path description, which is an address sequence representing an ordered list of gateways, except the last one may representing a host computer. Thus, together with the attached intranet hierarchies, the Internet becomes an "Internet hierarchy". Every node in this hierarchy is globally accessible and routable. Obviously, this will augment the IPv4 address capacity dramatically, as the Internet hierarchy can be far more larger then the Internet per se. This is because intranet addresses now can be used recursively and repeatedly within each intranet hierarchy. Further, the depth of each attached Intranet hierarchy can be extended freely as needed, using longer address sequences. The problem is how to carry the address sequences in the IP header. Actually, the idea of using address sequences is not new, R. Hinden [RFC3168] proposed a decade ago to use address sequences for next generation IP protocol. However, people preferred to use 128-bit addresses for IPv6, because a new protocol does not have to be based on IPv4, and thus restricted by IPv4. Nevertheless, as long as possible, it is better to manage to carry address sequences in the IPv4 header, so that the address shortage problem can be solved in an evolutional way, in contrast to the IPv6 revolution. For this purpose, two IPv4 header options, a Source-Side Path-Info (SSPI) and a Destination¿CSide Path-Info (DSPI), are added into the IPv4 protocol, so that path descriptions can be carried in the IPv4 header. In addition, a "path-based routing" algorithm is devised to ensure the "source address" and "destination address" fields in the IPv4 header always carry the IP addresses of 2 consecutive gateways along the path, except in the first hop and the last hop, where one address might be the IP address of a host computer. Particularly, when a packet is inside the Internet, these 2 fields typically will carry the Internet addresses of the 2 hierarchies, represented by their top-level gateways. In this way, Internet core routers need not be replaced or upgraded, because these routers will ignore the unrecognized new options when routing the IPv4 packets through. Path based routing is enforced by the gateways in the intranet hierarchies, level by level, and path-info options are inserted, extracted, and dealt with by the host computers supporting path based routing in both sides. Decao Mao Expires May 22, 2005 [Page 3] Internet Draft IPv4 Path Based Routing November 22, 2004 Further, a currently unused flag bit within the IPv4 header, the first bit of the "Flags" field, is defined to be used to extend the IPv4 header to include an extension block, so that new options can be carried "out-band" of the IP header, whose size is limited to 60 octets. 3. Path description A path description is an IP address sequence of variable length, consisting of an Internet address followed by a list of intranet addresses. A node's path description represents the path a packet should traverse from the top-level gateway down to the node within the hierarchy. The first address is the Internet address of the top-level gateway, and the following intranet addresses belong to the gateways along the path, level by level, in the top-down order. Identifying a node with path description greatly augments the IPv4 network capacity. For example, the capacity of the IPv4 Internet is about 2^32; the capacity of a single intranet 10.0.0.0/8 is 2^24; but the capacity of a 3-level intranet hierarchy is grater than 2^72. In other words, the capacity of a 4-level Internet hierarchy is 2^104, and in this case the path description length is 4 IPv4-addresses. The following example helps in better explaining the concept of path description and path based routing. (156.3.27.86) (101.202.10.11) @-{ The Internet Cloud }-@ 192.168.3.0/24 | | 192.168.100.0/24 ---------+----+-- -+-------+------- @ (192.168.3.45) @ (192.168.100.31) 10.40.0.0/16 | | 10.100.80.0/18 -----+----+---- --+--------+------- | @(10.100.80.3) H1 (10.40.18.2) | 192.168.100.0/24 ----+--+------- | H2 (192.168.100.31) Here '@' represents an intranet gateway, its address in the intranet or Internet it attaches is inside the parentheses. In addition, both H1 and H2 are host computers, whose intranet addresses are 10.40.18.2 and 192.168.100.31 respectively. For a particular packet transmission, suppose H1 is the source and H2 is the destination, and thus the left side is the source side and the right side is the destination side (to this particular packet). The source side top-level intranet gateway is (156.3.27.86), which is connected to the Internet, or the "public network". The intranet Decao Mao Expires May 22, 2005 [Page 4] Internet Draft IPv4 Path Based Routing November 22, 2004 attached to the Internet via the top-level gateway is 192.168.3.0/24. A second level gateway (192.168.3.45) is connected to the top-level intranet, introducing the second level intranet 10.40.0.0/16, to which H1 (10.40.18.2) is connected. Apparently, the source side in this case is a 2-level intranet hierarchy, and H1 can be uniquely identified and addressed with a source side path description of (156.3.27.86, 192.168.3.45, 10.40.18.2), in which the first address 156.3.27.86 is an Internet address, followed by 2 intranet addresses. Similarly, the destination side is a 3-level intranet hierarchy, and H2 can be uniquely identified and addressed with a destination side path of (101.202.10.11, 192.168.100.31, 10.100.80.3, 192.168.100.31). Note that the intranet address 192.168.100.31 appears twice in the path, which means intranet addresses can be used recursively inside a hierarchy, with the exception that 2 intranets connected to the same gateway MUST NOT use the same sub-network address. The whole itinerary of the packet from H1 to H2 can be divided into 3 legs, or segments. The first leg is the reversed source side path, which is given by the sender H1. The second leg is the path inside the Internet, which usually is unknown and dynamically changing, unless the source routing option is used. Actually, the path inside the Internet is usually not a concern, as long as the packet can eventually reach the destination, and that is the essence of IP networking. The last leg is the destination side path, which again is given by the sender H1. With variable length address sequences, as long as the length of the sequences is not limited, the capacity of the Internet hierarchy is also not limited. On the other hand, the number of available public IP address is no longer a problem, since only one public IP address is needed for an entire intranet hierarchy. In the extreme case, even a whole country can share one single Internet address. Obviously, both source side and destination side path descriptions should be carried in each packet. Gateways in both sides should have the ability to route packets based on the carried path descriptions, and so is called "path based routing". Note that each gateway has multiple IP addresses, the address appears in path descriptions is always the address for the up-link, namely the address of the port facing the direction of the public Internet. 4. Path descriptions as IPv4 options To carry source-side and destination-side path descriptions in the IPv4 header, 2 new IP options, Source-Side Path-Info (SSPI) and Destination-Side Path-Info (DSPI), are defined and added into the IPv4 protocol. Decao Mao Expires May 22, 2005 [Page 5] Internet Draft IPv4 Path Based Routing November 22, 2004 Both SSPI and DSPI have the same format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | OP Code |Length |Pointer| Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | First IP address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Second IP address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | . . . | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The format is similar to that of the IPv4 "Source Route" option, but is 4-byte boundary aligned. OP Code ¿C An 8-bit field for op-code. According to RFC 791, the op-code has an internal structure. The highest bit is the COPY bit, indicating that the option should be copied if the packet is to be segmented. Obviously, this bit must be 1 for packets carrying path-info options. The following 2 bits indicate the TYPE of the option, with 00 representing "datagram control". Then is the 5-bit "number" field identifying the particular options which is TBD1 and TBD2 for Source-Side Path-Info and Destination-Side Path-Info respectively. In other words, the code is 128+TBD1 for SSPI, and 128+TBD2 for DSPI. Length ¿C A 4-bit field for the address sequence length. Or, it can also be interpreted as the size of the address array. Pointer - A 4-bit field used as an index into the address array, indicating the IP address used in the current hop. IP addresses ¿C A sequence of IP addresses, or an array of IP addresses ip_addr[], representing the (full or partial) path of a particular node in its intranet hierarchy. A full path is an Internet address followed by one or more intranet addresses, while a partial path is just one or more intranet addresses which can only be used locally within an intranet hierarchy. To facilitate processing, as long as it exists, SSPI MUST be the first option in the IPv4 header. Similarly, as long as it exists, DSPI MUST be the second or the first option (if SSPI does not exist). 5. Path based routing In a typical itinerary, a packet traverses through 3 consecutive segments: the source side intranet segment, the middle Internet segment, and the destination side intranet segment. The first segment starts at the source node, going bottom-up through Decao Mao Expires May 22, 2005 [Page 6] Internet Draft IPv4 Path Based Routing November 22, 2004 the source side hierarchy, and ends at the top-level gateway of the hierarchy. Note that the top-level gateway is represented with the public IP address in the Source-Side Path-Info option. When a packet is sent, the source node does the following: 1) Create the source and destination side path-info options SSPI and DSPI (as needed), and put the options in the header, or in the extension block (see next section). 2) Inside the SSPI option, make the pointer point to the next hop, which is ip_addr[n-2] where n is the source-side path length. 3) Put the source IP address, namely the sender's IP address that is ip_addr[n-1], in the "source address" field of the basic IPv4 header. Put the next hop address, that is ip_addr[n-2], in the "destination address" field of the basic IPv4 header. 4) Inside the destination path option, set the pointer to 0, making it point to its first IP address ip_addr[0]. Within the source side hierarchy, gateway at each intermediate level does the following: 1) Update the "source address" field of the basic IPv4 header with the current destination which is pointed to by the pointer in the Source-Side Path-Info. 2) Move the pointer up, making it point to the next hop in the Source-Side Path-Info. 3) Update the "destination address" field of the basic IPv4 header with the new "current destination". 4) Route the packet, making it move up. When the packet arrives at the top-level gateway, the pointer in the source path-info option has been pointing to the top node in the source side segment, and the packet is going to enter the (middle) Internet segment, so the gateway does slightly differently: 1) Update the "source address" field of the basic IPv4 header with the gateway's own public address, which is the first element in the source side address sequence. 2) Update the "destination address" field of the basic IPv4 header with the public address of the top-level gateway in the opposite side, which is the first element in the destination side address sequence. 3) Route the packet, injecting the packet into the Internet. In this way, whenever a packet enters the public Internet, the "source address" and "destination address" fields always contain public addresses, to be used by the routers in the Internet. Note that routers (other than gateways) may exist in the intranet hierarchy, between two consecutive gateways. Such routers need not do anything special other than normal routing, using the addresses in the "destination address" field which points to the next gateway. Decao Mao Expires May 22, 2005 [Page 7] Internet Draft IPv4 Path Based Routing November 22, 2004 In the second segment, the packet goes through the Internet with both "source address" and "destination address" fields unchanged. To the routers in this segment, the path-info options are unknown options and will be ignored according to RFC 1812, "Requirements for IP Version 4 Routers". The last segment is the destination side segment. Starting at the top-level gateway of the destination side hierarchy, the packet goes down until ending at the destination node. Gateways in this hierarchy behave similarly to their counterparts in the source side hierarchy. The only difference is that the packet propagates in the opposite direction. Depending on the particular source node and destination node, source side segment and destination side segment may or may not exist respectively. For itineraries within an intranet hierarchy, both source node and destination node are in the same intranet hierarchy. In such cases, both source side and destination side path descriptions, and thus path-info options, can be simplified by canceling the common portion in both path-info options. Consequently, intranet gateways should be prepared to route such packets. 6. Logical IPv4 header extension Carrying source side and destination side path descriptions as IP options in IPv4 headers as described above makes it logically transparent to core routers, as the core routers will ignore the "unknown" IP options and simply route the packets as usual. Recall that the "Source Address" and "Destination Address" fields always carry the Internet addresses of the top-level gateways in both sides when a packet is in the Internet. However, such unknown "in-band" IP options carried in the IP header are not physically transparent to core routers. Many core routers are based on hardware routing engines. For these routers, while "ordinary" IPv4 packets with a basic header only (without any option) are routed by the hardware engine, packets with one or more options will be taken care of by the software (actually the CPU), which is much slower. Even for purely software based routers, packets without options take a "fast path", while packets with options will take a "slow path". Although eventually the options will be ignored and the packets will be routed through, the performance will be degraded. In other words, it is transparent in the functional perspective, but is not transparent in the performance perspective. In addition, the physical IPv4 header length is limited to 15 long words (60 bytes), that is because the "header length" field HLEN in the IPv4 header is a 4-bit field. Therefore, typically a path-info option is limited to 20 octets ((60 ¿C 20)/2, where 20 is the length of the basic IPv4 header). That means the typical maximum length of Decao Mao Expires May 22, 2005 [Page 8] Internet Draft IPv4 Path Based Routing November 22, 2004 a path description is 4 IPv4 addresses. In other words, the architecture of typical intranet hierarchy is limited to 3 layers, and thus the capacity of the Internet hierarchy is limited to 2^104. The ideal solution to this issue is: 1) making the existence of such options transparent to the core routers, so that core routers will not bother about dealing with options; and 2) extending the IPv4 header, so that both source and destination side path-info options can be carried "out-band" the normal IPv4 header. To make the existence of path-info options transparent to the core routers, these options should not be physically carried in the IPv4 header. In other words, the packet will have a header length of 5, indicating no option is carried in the header. Instead, the options are carried in an extension block physically outside the basic header, while the length of the extension block is counted into the total length of the packet. Therefore, logically the extension block belongs to the IPv4 header, but physically it is outside the header. To implement the extension, a flag bit 'E', the first bit in the 3-bit "flags" field, is used to indicate the existence of a variable length extension block. Since the flag bit is currently unused, core routers will not check this bit. This means the existence of options in the extension block is transparent to core routers, and thus the path-info options are physically transparent. The extension block can be used to carry path-info options and other possible new options. With the extension block, the basic IPv4 header format remains unchanged: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Vers | HLEN | Service Type | Total Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Identification |Flags| Fragment Offset | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Time to Lice | Protocol | Header Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source IP Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Destination IP Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The only difference is that the first bit in the "Flags" field is now defined as the E bit, the extension indication, while in the original IPv4 it is undefined. Actually, this is the only bit left unused so far. The 2 lower bits in the "Service Type" field were Decao Mao Expires May 22, 2005 [Page 9] Internet Draft IPv4 Path Based Routing November 22, 2004 also unused in the original IPv4 header, but now has been defined for explicit congestion notification in RFC 3168. If an IPv4 packet with the E bit set to 1, then a variable length extension block follows the basic header. Its length is counted into the "Total Length" field, but is not counted into the HLEN field in the header. The extension block has a format as following. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Magic | Flags | Length | Num | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Option 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Option 2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | . . . | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Here, the first long word is defined to be the block header, which is divided into 5 fields: Magic ¿C A 4-bit field for a magic code of 0xa, indicating this is the beginning of an IPv4 extension block. Flags ¿C A 4-bit field for flags. The definition of the flag bits is to be defined. One possible use is to define the first bit to indicate the extension block is encrypted. Length ¿C A 5-bit field for block length in 4-octat long words. Since the maximum number is 31, the block can be up to 124 octets long. The block header is counted into the block length. Num ¿C A 3-bit field for the number of options carried in the block. Option 1, Option 2, . . . ¿C Up to 7 options can be carried in the extension block. As long as it exists, SSPI MUST be the first option in the block. Similarly, as long as it exists, DSPI MUST be the second or the first option (if SSPI does not exist) in the block. Obviously, the use of out-band options is preferred to the use of in-band options, and therefore is RECOMMENDED. Note that the use of out-band options does not exclude the use of in-band options, and vice versa. Both can be used simultaneously. For example, while path-info options are carried in the extension block, other options can be carried in the IP header of the same packet. 7. Implementation and Deployment Considerations As an evolutional enhancement to the existing IPv4 protocols, it is Decao Mao Expires May 22, 2005 [Page 10] Internet Draft IPv4 Path Based Routing November 22, 2004 relatively easy to implement and deploy: 1) Routers (other than intranet gateways) need not be replaced or upgraded. Specifically, core routers need not be touched at all. The only exception is that the routers supporting RSVP and Intsrv will behave somehow differently, but core routers are more likely supporting Diffsrv rather than Intsrv. 2) Intranet gateways MUST implement path based routing described in section 5 above, for both in-band and out-band path options. 3) DNS (Domain Name System) software should be modified and enhanced, so that DNS servers can return path descriptions if necessary. 4) Host computer software should be modified and enhanced to take the advantages of path based routing, in particular: 4.1) DNS related software should be modified and enhanced to enable it to accept and use path descriptions. 4.2) The source side IP stack should be modified and enhanced to enable it to attach in-band or out-band path-info options into the IPv4 header. 4.3) The destination side IP stack should be modified and enhanced to enable it to use the attached path-info options for reply; and deduct the extension block length from the total packet length, so that the data potion can be correctly retrieved, if out-band path-info options are used. 8. Security Considerations Security considerations are not addressed in this document. The security perspective of path-based routing remains for further research. While a path-info option does expose more information about the node's topology position in the hierarchy, it is unlikely to degrade in the security perspective if compared to the current IPv4 protocol. On the other side, the use of the extension block for out-band options is an advantage which can be taken for security considerations. For example, new options can be added for usages such as authentication. In addition, the extension block can be encrypted to protect the path information from eavesdropping. 9. IANA Considerations Section 4 defines both source-side and destination-side path-info options. The "number" field inside the op-code of SSPI is assigned the value TBD1, and that of DSPI is assigned the value TBD2. Section 6 requires to use the first bit in the flags field in IPv4 header, which is to be approved by the IANA. RFC EDITOR's NOTE (to be removed prior to publication): the IANA is requested to assign two values for TBD for two new options, and approve the use of the flag bit. When the assignment has been made, the RFC Editor is asked to replace "TBD1" and "TBD2" in section 4 Decao Mao Expires May 22, 2005 [Page 11] Internet Draft IPv4 Path Based Routing November 22, 2004 with the assigned values and to remove this note. Also, the RFC Editor is asked to change the above clause "to be approved by the IANA" into "approved by the IANA". 10. References [RFC0791] Information Sciences Institute, "Internet Protocol", RFC 791, September 1981. [RFC1710] R. Hinden, "Simple Internet Protocol Plus White Paper", RFC 1710, October 1994. [RFC1752] S. Bradner, "The Recommendation for the IP Next Generation Protocol", RFC 1752, January 1995. [RFC1812] F. Baker, "Requirements for IP Version 4 Routers", RFC 1812, June 1995. [RFC3168] K. Ramakrishnan, S. Floyd, D. Black, "The Addition of Explicit Congestion Notification (ECN) to IP", RFC 3168, September 2001 Authors' Addresses Decao Mao Insigma Technology Co., Ltd. C-12, World Trade Center Hangzhou, 310007 Peoples Republic of China Phone: +571 8795 0885 Email: decaomao@yahoo.com Full Copyright Statement Copyright (C) The Internet Society (2004). 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. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY(IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property 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. Decao Mao Expires May 22, 2005 [Page 12] Internet Draft IPv4 Path Based Routing November 22, 2004 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 http://www.ietf.org/ipr. 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 ietf-ipr@ietf.org.