NEMO Working Group Jongkeun Na Internet Draft Seongho Cho Expires: November 2004 Chongkwon Kim Seoul National University Sungjin Lee Hyunjeong Kang Changhoi Koo Samsung Electronics April 2004 Route Optimization Scheme based on Path Control Header draft-na-nemo-path-control-header-00 Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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 obsoleted 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. Abstract In this memo, we propose a unified Route Optimization (RO) scheme that can solve several types of RO problem by using Path Control Header (PCH) Piggybacking. In our scheme, Home Agent (HA) does piggyback the PCH on the packet which is reversely forwarded from Mobile Router (MR). That enables any PCH-aware routing facility on Na, et al. Expires - November 2004 [Page 1] Internet Draft Path Control Header April 2004 the route to make a RO tunnel with MR using the Care-of address of MR contained in the PCH. By applying to some already known NEMO RO problems, we show that our scheme can incrementally optimize the routes via default HA-MR tunnel through the simple PCH interpretation. 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 RFC-2119. Na, et al. Expires - November 2004 [Page 2] Internet Draft Path Control Header April 2004 Table of Contents 1. Introduction.................................................4 2. Terminology..................................................5 3. Basic Operations.............................................6 3.1 PCH Piggybacking by HA..................................6 3.2 Making a RO Tunnel......................................7 4. Route Optimization...........................................9 4.1 Route Optimization by CR................................9 4.2 Route Optimization over MR-to-MR.......................10 4.3 Nested Tunnels Optimization............................12 5. Extensions..................................................15 5.1 MIPv6 Extension........................................15 5.2 MR Extension...........................................18 5.3 HA Extension...........................................18 6. Security Considerations.....................................19 References......................................................20 Acknowledgments.................................................21 Authors' Addresses..............................................21 Na, et al. Expires - November 2004 [Page 3] Internet Draft Path Control Header April 2004 1. Introduction NEMO Basic Support Solution[15] would suppose to support transparent mobility to mobile network nodes(MNNs) in mobile networks by using MR-HA bi-directional tunneling. However, inherently due to the use of the bi-directional tunnel, there are some types of route optimization problem [14] that need our attention. Until now, one solution is proposed to solve only one type of route optimization problem such as nested tunnel optimization. In this memo, we propose a route optimization scheme based on PCH(Path Control Header) piggybacking by HA. The scheme is a unified solution that can solve a several types of route optimization problem with applying the same principle to the routing facilities such as HA, MR and Correspondent Router(CR). In the proposed scheme, HA does piggyback PCH on the packet which is reversely forwarded from MR through bi-directional MR-HA tunnel. PCH is a hop-by-hop option header so that it can be processed by all of the routing facilities on the path that is from HA to CN. HA forwards the packet with PCH to CN for the route optimization. CR on the path makes a RO(Route Optimization) tunnel between MR and itself using the information which is the CoA of MR that is contained in PCH. This memo describes how we can apply PCH based scheme on two problem spaces listed in [14]. One is to CR based route optimization in routing infrastructure and the other is to the nested tunnels optimization for which many of solutions in NEMO have been proposed. The basic operation and signaling will be detailed in section 3 and 4. Our proposed RO scheme, PCH piggybacking by HA, is a simple but effective one in solving the problems of route optimization in network mobility support. By taking the functional extension of routing facilities such as HA, MR and CR, we can dynamically incrementally optimize the routes over CN-HA-MR without the loss of transparency to CN. We expect that the basic concept of this scheme can be used to support other mobility-related route optimizations as a unified solution, not limited to network mobility. Na, et al. Expires - November 2004 [Page 4] Internet Draft Path Control Header April 2004 2. Terminology It is assumed that readers are familiar with NEMO terminology described in [2][14], and the terms described in [4][5]. In addition, we define a few of terms used in describing the operation of our solution. Path Control Header (PCH) IPv6 hop-by-hop option header piggybacked on the reversely forwarded packet by HA for the route optimization. This header contains, as an option data, a form of array of IPv6 global addresses that are the addresses of Mobile Routers on the nested path which means from TLMR to any nested MR in nested mobile networks. RO Tunnel (ROT) Any tunnel that created by the scheme of route optimization proposed by this document is referred to a "RO Tunnel”. Nested RO Tunnel (NROT) Any RO tunnel that do require the source routing using IPv6 Routing Header Type 0 (RH0). This kind of RO tunnel is only used in optimizing the nested tunnels to guarantee the correct routing over nested MRs. Correspondent Router (CR) Any router in the Internet that can play a role of a correspondent agent for a set of correspondent nodes. It maybe an access router serving the routing service to a set of subnets or a border router located in AS-level or ISP- level. Na, et al. Expires - November 2004 [Page 5] Internet Draft Path Control Header April 2004 3. Basic Operations 3.1 PCH Piggybacking by HA To route optimization, HA does piggyback PCH on the packet which is reversely forwarded from MR through bi-directional MR-HA tunnel. PCH is a hop-by-hop option header so that it can be processed by all of the routing facilities on the path that is from HA to CN. The mentioned routing facility means an entity which can play a role of transparent correspondent agent. The router in the Internet that implements such a function of transparent correspondent agent, we call it a CR, provides the packet redirection service to the nodes behind it by intercepting the packets sent from them and redirecting to the RO tunnel. The RO tunnel between CR and MR can be established when CR gets know the existence of HA by processing the packet with PCH. In fig.1, HA de-capsulates the encapsulated packet forwarded from MR via MR-HA tunnel and then forwards the PCH piggybacked packet to CN for the route optimization. Any existing CR on the path from HA to CN can catch the path control information as examining PCH in the packet. Therefore, the CR can initiate the procedure of making RO tunnel between itself and MR using the CoA of MR which is contained in PCH. After setting up RO tunnel, the packets of CN will be redirected to RO tunnel at CR. +----+ IP in IP CN <--- Packet with PCH --- | HA |<==== Packet ==== MR | +----+ =[1|CoA of MR] Fig.1 PCH piggybacking by HA This scheme is simple and effective in respects of RO. It only requires a little effort of HA to provide the RO tunnel between CR and MR. HA does PCH piggybacking on the packet which taking a non- optimized path of MR-HA tunnel. In here, we can say that CR maybe an access router that providing the routing service for a few of subnets or a border router that runs BGP routing protocol in one AS. Fig.2 shows the structure of PCH. PCH has address information as an option data. In here, the address information represents the list of IPv6 addresses. The address contained in PCH indicates the CoA of MR in MR-HA relationship. Through PCH, CR gets know the CoA of MR so that CR can initiate the signaling for RO tunnel. Na, et al. Expires - November 2004 [Page 6] Internet Draft Path Control Header April 2004 PCH(Path Control Header) : IPv6 Hop-by-Hop Options Header Option Type : 00 0 XXXXX 00 - skip over this option and continue processing the header. 0 - Option Data does not change en-route XXXXX = Path Control Option ID (to be assigned by IANA) Option Data : +-----------+------------+------------+---------+------------+ | Length(n) | Address(1) | Address(2) | . . . . | Address(n) | +-----------+------------+------------+---------+------------+ Fig.2 Type and data format of PCH option In fig.3 that shows the case of forming nested tunnels, PCH gets contain two CoAs, each of MR1 and MR2. HA2 gets know the fact that its MR2-HA2 tunnel is nested under outer MR1-HA1 tunnel after taking a look at the packet with PCH1. The nested HA just adds the CoA of its MR on the received PCH to make its PCH. In fig.3, HA2 does piggyback PCH which includes the CoA of MR1(the exit point of the outer tunnel) and the CoA of MR2(the exit point of its tunnel). In this case, one CR on the path between HA2 and CN will able to make RO tunnel with MR2 by using the nested information carried in PCH. +---+ +---+ +---+ +---+ CN <----|HA2|=========|HA1|////////|MR1|========|MR2|<----LFN \ +---+ \ +---+ +---+ +---+ \ PCH=[1|CoA of MR1] PCH=[2|CoA of MR1, CoA of MR2] Fig.3 Nested PCH piggybacking by HAs 3.2 Making a RO Tunnel The CR can make a RO tunnel after getting the piggybacked PCH from HA. The signaling to construct a RO tunnel between CR and MR is done with 3-way handshake as in fig.4. The messages defined in here are carried by Mobility Header(MIPv6). We define new message called “BR(Binding Request)” to notify MR of the need of RO tunnel. BU(Binding Update) and BA(Binding Acknowledgement) are same as defined in MIPv6 and NEMO. Additionally, we define new mobility option to carry a set of network prefixes. CR can use this option to inform MR of the routing information of networks which are reachable from RO tunnel. By referring those of routing information, MR reversely forwards the packets to pre-established RO tunnel Na, et al. Expires - November 2004 [Page 7] Internet Draft Path Control Header April 2004 because they are destined to the network that is reachable from RO tunnel. CR does the same thing for the prefix of mobile network that is bound through BU from MR. CR intercepts the packets destined to the prefix and redirects them to pre-established RO tunnel. CR MR | | |----- Binding Request(BR) -------->| | | |<---- Binding Update(BU)-----------| | | |----- Binding Ack.(BA)------------>| | | |<======== RO tunnel ==============>| | | Fig.4 The signaling procedure for RO Tunnel Na, et al. Expires - November 2004 [Page 8] Internet Draft Path Control Header April 2004 4. Route Optimization 4.1 Route Optimization by CR HA1 | ===*==== |& CR1(Border Router) \ +---------------------+ | Internet |--CR2 ====|=== +---------------|-----+ CN1 / AR(Access Router) CN2 | ======*=========== MR1 | LFN1 Fig.5 CR-based Route Optimization : Network Configuration As in fig.5 and 6, CR1 and CR2 can simultaneously establish a RO tunnel with MR through one PCH piggybacking by HA1. This is possible because both are on the path that is from HA1 to CN1. In that case, the packets sent from CNs in all of subnets attached to CR2 are redirected to RO tunnel at CR2. CR1 can serve the packets sent from any CNs(in here, CN2) that are scattered in the Internet. The packets reached on CR1 indicate that there is no CR in the path that is from CN2 to CR1, or CR but still not received PCH. The packets from CN2 are redirected at CR1 and reversely the packets from MR1 are forwarded via HA1. At next time, the CR on the CR1-CN2 path can make a RO tunnel by picking PCH up on the reversely forwarded packets from HA1. As a result of PCH piggybacking by HA1, we can serve the incremental route optimization to all of CNs. Na, et al. Expires - November 2004 [Page 9] Internet Draft Path Control Header April 2004 CN1 CN2 CR2 CR1 HA1 MR1 LFN1 | | | | | | | | | | | | Tunnel | | |----------Packet------------------>|========|------->| |<+++Packet(PCH)++|<+++++++|<+++++++|========|<-------| | | | |------- BR ----->| | | | | |<------ BU ------| | | | | |------- BA------>| | | | | |<== RO tunnel ==>| | | | | | | | | | | |----------- BR ---------->| | | | |<---------- BU -----------| | | | |----------- BA ---------->| | | | |<======= RO tunnel ======>| | | | | | | | | |---------------->|==========================|------->| |<----------------|==========================|<-------| | | | | | | | | |---------------->|=================|------->| | |<+++++++++++++++++++++++++|========|<-------| | | | | | | | Fig.6 CR-based Route Optimization : Message Flow 4.2 Route Optimization over MR-to-MR As in fig.7 and fig.8, we can get the RO tunnel over MR-to-MR by using PCH piggybacking. MR per se interprets PCH piggybacked from the HA of the other MR and initiates the signaling for RO tunnel with the other MR. As a result of that, the nodes behind one MR can directly communicate with the nodes behind the other MR without any routing overhead. Na, et al. Expires - November 2004 [Page 10] Internet Draft Path Control Header April 2004 LFN2 | MR2 ===*==== | AR(Access Router) \ +---------------------+ | Internet |--HA1 +---------------|-----+ / AR(Access Router) HA2 | ======*=========== MR1 | LFN1 Fig.7 MR-to-MR Route Optimization : Network Configuration LFN1 MR1 HA1 HA2 MR2 LFN2 | | | | | | | | Tunnel | | Tunnel | | |------->|========|+++++++>|========|+++++++>| | | | | | | | |<---------- BR -----------| | | | | | | | | |----------- BU ---------->| | | | | | | | | |<---------- BA -----------| | | | | | | | | |<======= RO Tunnel ======>| | | | | | | | |<-------|==========================|<-------| | | | | | | | | | | | | Fig.8 MR-to-MR Route Optimization : Message Flow Na, et al. Expires - November 2004 [Page 11] Internet Draft Path Control Header April 2004 4.3 Nested Tunnels Optimization Fig.9 and 10 show the network configuration and message flow for the nested tunnels optimization using PCH piggybacking. In nested mobile networks, RO tunnel is called “Nested RO Tunnel(NROT)” because we introduces the source routing concept in handling the nested tunnel optimization. To the correct routing in the nested network configuration, we take advantage of IPv6 Routing Header Type 0(RH0) in NROT. HA1 | ===*==== |& AR(Access Router) \ +---------------------+ HA2--| Internet |--CR====|=== +---------------|-----+ CN / AR(Access Router) HA3 | ======*=========== MR1(TLMR) | ====*=============|=================*========== MR2 LFN1 MR4 | | =======*==== ================?==== MR3 VMN | ====|=======|===== LFN3 LMN Fig.9 Nested Tunnels Optimization : Network Configuration In fig.10, CR gets know the existence of nested tunnels through PCH information (MR1’s CoA and MR2’s CoA, MR3’s CoA) and then initiate the signaling for NROT to MR3 via nested tunnels. At this time, Binding Request(BR) message contains Nested Routing Path Option(NRP Option). NRP Option is used to inform MR3 of the nested path information. If MR3 receives BR message having NRP option, MR3 also gets know that it is nested. Therefore, the tunnel between CR and MR3 becomes a NROT. In NROT, the entry point of tunnel adds RH0 at encapsulation. Reversely, the exit point of tunnel deletes RH0 at decapsulation. Na, et al. Expires - November 2004 [Page 12] Internet Draft Path Control Header April 2004 For the packets tunneled from CR to MR3, the packet forwarding is done with source routing of RH0 (MR1->MR2->MR3). For the packets tunneled from MR3 to CR, the reverse source routing (MR2->MR1->CR) occurs. Fig.11 and 12 shows the content of RH0 at the packet delivery. LFN3 MR3 MR2 MR1 HA1 HA2 HA3 CR CN | | | | | | | | | | | | |\\\\\\| | | | | | | |//////|//////|//////| | | | |----->|======|======|======|======|======|+++++>|++++>| | | |//////|//////|//////| | | | | | | |\\\\\\| | | | | | | | | | | | | | | |<----------------- BR -------------------| | | |------------------ BU ------------------>| | | |<----------------- BA -------------------| | | | | | | | | | | | |<========== Nested RO Tunnel ===========>| | | | | | | | | | | | |Source routing | | | | | |<-----|<<====|<<====|<<=========================|<----| | | | | | | | | | |----->|====>>|====>>|=========================>>|---->| | | | | | | | | | Fig.10 Nested Tunnels Optimization : Message Flow Na, et al. Expires - November 2004 [Page 13] Internet Draft Path Control Header April 2004 <--------------- outer IPv6 header ---------------> +-------+-------++ -- ++----+---+--------+---------++-------- |oSRC |oDST |: :|oRH |LS |Addr[1] | Addr[2] || CR :| CR |MR1-CoA|:oEXT:|type| 2 |MR2-CoA | MR3-CoA || iPACKET | | |: :| 0 | | | || +-------+-------++ -- ++----+---+--------+---------++-------- <--------------- outer IPv6 header ---------------> +-------+-------++ -- ++----+---+--------+---------++-------- |oSRC |oDST |: :|oRH |LS |Addr[1] | Addr[2] || MR1:| CR |MR2-CoA|:oEXT:|type| 1 |MR1 | MR3-CoA || iPACKET | | |: :| 0 | | | || +-------+-------++ -- ++----+---+--------+---------++-------- <--------------- outer IPv6 header ---------------> +-------+-------++ -- ++----+---+--------+---------++-------- |oSRC |oDST |: :|oRH |LS |Addr[1] | Addr[2] || MR2:| CR |MR3-CoA|:oEXT:|type| 0 |MR1 | MR2 || iPACKET | | |: :| 0 | | | || +-------+-------++ -- ++----+---+--------+---------++-------- Fig.11 Forward Packet Delivery (CR->MR3) via NROT <--------------- outer IPv6 header ---------------> +-------+-------++ -- ++----+---+--------+---------++-------- |oSRC |oDST |: :|oRH |LS |Addr[1] | Addr[2] || MR3: |MR3-CoA| MR2 |:oEXT:|type| 2 |MR1 | CR || iPACKET | | |: :| 0 | | | || +-------+-------++ -- ++----+---+--------+---------++-------- <--------------- outer IPv6 header ---------------> +-------+-------++ -- ++----+---+--------+---------++-------- |oSRC |oDST |: :|oRH |LS |Addr[1] | Addr[2] || MR2: |MR2-CoA| MR1 |:oEXT:|type| 1 |MR3-CoA | CR || iPACKET | | |: :| 0 | | | || +-------+-------++ -- ++----+---+--------+---------++-------- <--------------- outer IPv6 header ---------------> +-------+-------++ -- ++----+---+--------+---------++-------- |oSRC |oDST |: :|oRH |LS |Addr[1] | Addr[2] || MR1: |MR1-CoA| CR |:oEXT:|type| 0 |MR3-CoA | MR2-CoA || iPACKET | | |: :| 0 | | | || +-------+-------++ -- ++----+---+--------+---------++-------- Fig.12 Reverse Packet Delivery (MR3->CR) via NROT Na, et al. Expires - November 2004 [Page 14] Internet Draft Path Control Header April 2004 5. Extensions The proposed scheme requires some extensions for existing MIPv6 and NEMO Basic Support protocols. 5.1 MIPv6 Extension The proposed scheme requires some extensions for existing MIPv6 protocol [1]. As you see in section 3.2, new mobility message, BR, is required. And also, new two mobility options are needed. We describe the purpose and usage of them in here. Binding Request Message (BR Message): This message is used to notify MR of the need of RO tunnel. If the sender of this message detects the nested tunneling(i.e. PCH contains one more addresses), it should put NRP(Nested Routing Path) Option into this message to inform MR of its nested path information. Otherwise, this message includes no special information except for triggering the signaling of RO tunnel. Nested Routing Path Option (NRP Option): The initiator of the signaling of RO tunnel should add this mobility option in BR message to set up the Nested RO Tunnel with nested MR. This option contains the list of addresses that represents the tree topology of nested MRs. That is used for MR to assign the source routing path that is necessary to nested tunnels optimization. Reachable Network Prefixes Option (RNP Option): This option is used to let MR know about the network prefixes which are reachable via RO tunnel. By using this information associated with RO tunnel, MR can select the optimized path(i.e. RO tunnel) for the out-going packets. This option should be contained in BA message. 5.1.1 Binding Request Message (BR Message) New BR Message is defined to notify MR of the need of RO tunnel. If sender detects the nested mobility, it has to put NRP Option into in this message to inform MR of its nested path information. The format of this message is as follows: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence # | Na, et al. Expires - November 2004 [Page 15] Internet Draft Path Control Header April 2004 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . . . Mobility options . . . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ TBD 5.1.2 Reachable Network Prefixes Option (RNP Option) RNP Option is used to let MR know about the networks reachable via the tunnel. By using this information associated with the tunnel between CR and MR, MR can select the optimized path for the out- going packets. This option should be contained either BR or BA message for the route optimization in the reverse packet delivery. The format of this option is as follows: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = TBA | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + a set of network prefixes + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ TBD Na, et al. Expires - November 2004 [Page 16] Internet Draft Path Control Header April 2004 5.1.3 Nested Routing Path Option (NRP Option) CR adds new mobility option, NRP Option in BR message to set up the Nested RO Tunnel with nested MR. The format of this option is as follows: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = TBA | Length=16*n | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | NP_Length=n | Reserved | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Addr[1](=TLMR address) + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | o | | o | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Addr[n] + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ NP_Length 8-bit unsigned integer that indicates the number of Addr[] slots. Addr[1..n] Vector of IPv6 global addresses of MRs on the nested path, numbered 1 to n. NRP Option is only valid in a Binding Request message. The purpose of this option is to inform MR that it can do optimize the nested tunnels overhead. Using this information, MR can route packets to Na, et al. Expires - November 2004 [Page 17] Internet Draft Path Control Header April 2004 CR via the MRs on the nested path by using type 0 RH optional header. 5.2 MR Extension For route optimization, MR MUST understand BR message sent from routing facilities such as CR. According to MIPv6 Spec.[1], MR MUST maintain Binding Update List(BU List). In managing BU List, the following information MUST be maintained additionally to use RO tunnel defined in this proposed solution. RO Tunnel (ROT) flag: When it is set, it indicates that the associated BU entry is for ROT tunnel. All of ROT tunnel should contain a set of network prefixes that is carried from RNP Option. Nested RO Tunnel (NROT) flag: When it is set, it indicates that the associated BU entry is for NROT tunnel. In this case, the BU entry should contain the nested path information carried from NRP Option. Nested Path Information (NPI) Vector: The address vector information is transferred in NRP Option. This information is only valid when NROT flag is set. Network Prefixes (NP) Vector: The address vector information transferred in RNP Option. This information is only valid when either ROT flag or NROT flag is set. The successful establishment of RO tunnel allows the ready of RO- enabled tunnel interface that would be associated with the correspondent entry of BU List. That tunnel interface should be setup to add IPv6 RH0(Routing Header Type 0) optional header at the encapsulation of tunneled packets if the NROT flag is set. Lastly, MR should maintain the RO tunnels in its own context. In other words, MR can tear down less necessary RO tunnels according to its own criterion such as Least Recently Used(LRU) in case of the resource shortage. 5.3 HA Extension For route optimization, HA should maintain the state of PCH piggybacking for per traffic flow. The traffic flow can be classified by the destination address of the packets. HA does piggyback PCH on one packet per the traffic flow. The piggybacking state should be managed by soft-state. The piggybacking state of Na, et al. Expires - November 2004 [Page 18] Internet Draft Path Control Header April 2004 per traffic flow becomes set when the first packet is piggybacked and reset when the state timer is expired. HA doesn’t need to piggyback PCH on the packets belong the traffic flow while the correspondent state is set. The overhead of managing the piggybacking state can be minimized by the careful implementation. According to MIPv6 Spec.[1], HA MUST maintain Binding Cache(BC). Like MR extension. Additionally, HA manages the following information in associated BC entry for route optimization. Route Optimization (RO) flag: When it is set, it indicates that the associated BU entry is RO enabled. RO may be enabled or disabled by administrative means. Piggybacking State Table (PST): An entry of this table represents a record that contains (“flow-id” = destination address, “time-info” = UTC time). It indicates that the first packet belong the traffic flow(=”flow-id”) was piggybacked with PCH at time(=”time-info”). For the packets forwarded via RO enabled tunnel from MR, HA decapsulates them, and checks the need of PCH piggybacking. If an entry that contains the destination address of the packet exists in PST, PCH is not piggybacked to the packet at forwarding. Otherwise, HA creates new entry in PST for that traffic flow and piggybacks PCH on the packet at forwarding. We can use one global timer to delete the records which were long sustained in PST. 6. Security Considerations TBD In particular, considering security concerns is very important in applying the Internet protocol. At this moment, Public Key Infrastructure (PKI) can be a solution to support the integrity and the origin-authentication of PCH because the participants in our scheme are limited to some of routing facilities. We know that the potential security problem of our scheme must be deeply considered. We leave the detailed security consideration into the future work item with high priority. Na, et al. Expires - November 2004 [Page 19] Internet Draft Path Control Header April 2004 References [1] Perkins, C., Johnson, D. and J. Arkko, "Mobility Support in IPv6", draft-ietf-mobileip-ipv6-18 (work in progress), July 2002. [2] Ernst, T. and H. Lach, "Network Mobility Support Terminology", draft-ietf-nemo-terminology-00 (work in progress), May 2003. [3] Ernst, T., Castelluccia, C., Bellier, L., Lach, H. and A. Olivereau, "Mobile Networks Support in Mobile IPv6 (Prefix Scope Binding Updates)", draft-ernst-mobileip-v6-network-03 (work in progress), March 2002. [4] Thubert, P., and Molteni, M., "IPv6 Reverse Routing Header and Its Application to Mobile Networks", Internet Draft: draft-thubert-nemo-reverse-routing-header-01 (work in progress), Oct 2002. [5] Chan-Wah Ng, and Takeshi Tanaka, "Securing Nested Tunnels Optimization with Access Router Option", Internet Draft:draft -ng-nemo-access-router-option-00(work in progress), Oct 2002. [7] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998. [8] Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2402, November 1998. [9] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload (ESP)", RFC 2406, November 1998. [10] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998. [11] Narten, T., Nordmark, E. and W. Simpson, "Neighbor Discovery for IP Version 6 (IPv6)", RFC 2461, December 1998. [12] Conta, A. and S. Deering, "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification", RFC 2463, December 1998. [13] Reynolds, J., "Assigned Numbers: RFC 1700 is Replaced by an On-line Database", RFC 3232, January 2002. [14] Thubert, P., and Molteni, M., "Taxonomy of Route Optimization Models in the NEMO Context", Internet Draft: draft-thubert- nemo-ro-taxonomy-00(work in progress), Oct 2002. Na, et al. Expires - November 2004 [Page 20] Internet Draft Path Control Header April 2004 [15] vijay, D., Ryuji, W., Alexandru, P., Pascal, T., "NEMO Basic Support Protocol", draft-ietf-nemo-basic-support-00(work in process), June 2003. [16] A. Conta, S. Deering, "Generic Packet Tunneling in IPv6 Specificiation", RFC2473, December 1998. Acknowledgments Authors' Addresses Jongkeun Na Information Networking & Computing Lab. School of Computer Science and Engineering, Seoul National University, Seoul Korea EMail: jkna@popeye.snu.ac.kr Sungho Cho Information Networking & Computing Lab. School of Computer Science and Engineering, Seoul National University, Seoul Korea EMail: shcho@popeye.snu.ac.kr Chongkwon Kim Information Networking & Computing Lab. School of Computer Science and Engineering, Seoul National University, Seoul Korea EMail: ckim@popeye.snu.ac.kr Sungjin Lee Global Standards & Research Team Telecommunication R&D Center, Samsung Electronics, KOREA Email : steve.lee@samsung.com Hyunjeong Kang Global Standards & Research Team Telecommunication R&D Center, Samsung Electronics, KOREA Email : hyunjeong.kang@samsung.com Changhoi Koo Global Standards & Research Team Telecommunication R&D Center, Na, et al. Expires - November 2004 [Page 21] Internet Draft Path Control Header April 2004 Samsung Electronics, KOREA Email : chkoo@samsung.com Na, et al. Expires - November 2004 [Page 22]