NSIS Working Group Internet Draft T. Sanda T. Ue H. Cheng Document: draft-sanda-nsis-path-type-00.txt Panasonic Expires: April 2005 October 2004 Path type support for NSIS signaling draft-sanda-nsis-path-type-00.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of 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 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 NSIS state management needs to track data path changes and update the states along the affected data paths. However, in certain scenarios, it also needs to be aware of the path type to achieve appropriate operations. For example, a triangular path and a route-optimized path for a MN at the same location may involve in a communication session when Mobile IP is employed. Therefore, certain functionality for data path distinction is necessary in the NSIS signaling. This draft discusses the problems and issues involved in the NSIS state management relevant to the data path differentiation. Specific scenarios for Mobile IP route optimization procedure are used for illustration of the problems. Potential solution and its impacts on current NSIS protocol design are discussed as well. T. Sanda et al. Expires - April 2005 [Page 1] Internet-Draft Path type support for NSIS signaling October 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 RFC-2119 [1]. Table of Contents 1. Introduction...................................................2 2. Terminology....................................................3 3. Motivation of study............................................3 3.1 Backgrounds for the Route Optimization issue................3 3.2 Problems for the NSIS support of RO.........................5 4. Identifiers for TR path and RO path signaling..................6 4.1 Utilizing different Session IDs.............................7 4.2 Utilizing the same Session ID...............................8 4.2.1 Flow ID based on HoA and CN address for whole TR path...8 4.2.2 Different Flow IDs for different section of TR path.....9 4.2.3 Flow ID based on CoA of MN and CN address for TR path..10 5. Solution Requirement Analysis.................................10 5.1 Requirements for the RO procedure support..................10 5.2 Other requirements relevant to NSIS identifiers............11 5.2.1 Use of packet classifier vs. Flow ID...................11 6. Security Considerations.......................................12 7. Conclusions...................................................13 References.......................................................13 Author's Addresses...............................................13 Intellectual Property............................................15 Full Copyright Statement.........................................15 1. Introduction In the defined NSIS framework [2], a two-layer architecture is used, wherein the NTLP layer handles the general message routing and transport and NSLP layer carries out the actual signaling application. The GIMPS draft [3] defines the NTLP layer, and the QoS NSLP draft [4] specifies an instance of the NSLP signaling application for the QoS provisioning and control. These drafts are focusing on basic NSIS specifications and do not include detailed considerations for mobility related issues. A mobility event is usually accompanied with data path changes. Therefore, for the path coupled solution like NSIS, mobility support requires extra handling functionalities, e.g. path monitoring, crossover node discovery, flow identifier manipulation, etc. These aspects are not fully explored. Some general discussions about the mobility support are available in the Applicability Statement draft T. Sanda et al. Expires - April 2005 [Page 2] Internet-Draft Path type support for NSIS signaling October 2004 [5] from the viewpoint of effects that mobility can cause to the NSIS protocols. However, most of the specific issues related to mobility support are excluded by request. This draft addresses a basic mobility issue, Route Optimization (RO), which would be faced by the NSIS framework in the Mobile IP environment. RO is a basic function provided by Mobile IPv6 (MIPv6) [6] to avoid wasting network resources. When a successful RO is performed, data will flow directly between the Correspondent Node (CN) and the Mobile Node (MN) without going through the Home Agent (HA). Since the RO procedure makes use of the triangular (TR) path (path via the HA), it will always happen after the TR path is set up. Therefore, there is always a data path change involved in the RO procedure, even though there is no actual address change. This constitutes a problem for the operations of the NSIS protocols defined in [3,4]. In this draft, details of the problem and some possible solutions are discussed. Impacts on the current protocol design, and the advantage and disadvantage of each solution are also analyzed in the subsections of the draft. Although there are RO solutions based on Mobile IPv4, it is not commonly used. This draft focuses only on the RO issues related to MIPv6. 2. Terminology The Terminology defined in [3,4] applies to this draft. In addition, the following terms are used: TR path: Triangular Path. A route between MN and CN with tunneled RO path: Route Optimized path. A direct route between MN and CN 3. Motivation of study 3.1 Backgrounds for the Route Optimization issue As mentioned earlier, this draft focuses on the RO issues of the MIPv6. As described in MIPv6 [6], the RO will be performed if both the MN and the CN supports it. With optimization, data traffic will flow directly between MN and CN without going through the HA. This improves the efficiency of network resources utilization, and reduces the communication dependency on the MN's Home network. Due to the MIPv6 security requirements, a Return Routability procedure must be carried out during the RO. Therefore, the data path through the HA needs to be available before the RO is carried out. Below, a typical use case is described for the better analysis of the issue. T. Sanda et al. Expires - April 2005 [Page 3] Internet-Draft Path type support for NSIS signaling October 2004 Figure 1 shows a typical scenario for the MIPv6 RO procedure. When the MN A with a Home Address HoA-A enters a network, it first obtains a local address, e.g. CoA-C, and registers this address as its new Care-of-Address (CoA) with its HA of which IP address is HA-E. After this, communication session between MN A and CN B could be established through the HA. This is the TR path. Detail packet encapsulation is shown in the upper part of the figure. Outer Src:CoA-C Dst:HA-E Inner Src:HoA-A Dst:CN-B +--+ Src:HoA-A Dst:CN-B --)--)--)--)--)--)--)--)--)-->| |------------------------ | |HA| | | -(--(--(--(--(--(--(--(--(--| |<--------------------- | | | Outer Src:HA-E Dst:CoA-C +--+ Src:CN-B Dst:HoA-A | | | | Inner Src:CN-B Dst:HoA-A | | | | | | | | | | | v | v +----+ Src:CoA-C Dst:CN-B Dest Opt:HoA-A +----+ | |*************************************************>| | |MN A| |CN B| | |<*************************************************| | +----+ Src:CN-B Dst:CoA-C Type 2 RH:HoA-A +----+ ----> data packets via TR path --)--) tunneled data ****> data packets via RO path (--(-- tunneled data Figure 1. Data paths before and after the RO procedure For the resource reservation over this TR path, it is obviously split into two sections: from HA to CN B, and from HA to MN A. Since the data traffic is tunneled between MN A and the HA, the NSIS signaling over this section needs to interact with the tunneling protocols. Based on current NSIS protocols, certain measure as discussed in [8] should be employed. In such a case, the HA or the MN A has to be signaling aware and handles the signaling for tunneled data traffic. Over the path between HA and CN B, the signaling message is processed per normal as long as the HA can properly handle the encapsulation and decapsulation of the message. For the TR path signaling, the CN B end is not aware of the address change at the MN A. T. Sanda et al. Expires - April 2005 [Page 4] Internet-Draft Path type support for NSIS signaling October 2004 After a successful RO procedure, the CN B will create a binding cache for the MN A's care of address, CoA-C. In this case, data traffic flows directly between MN A and CN B. Detailed packet encapsulation is shown in the lower part of Figure 1. NSIS signaling over the RO path will be based on the CoA of MN and the CN address. This requires the interaction between the NSIS layer and the MIPv6 layer. Whenever the MN-A changes its CoA, e.g. by moving to a new subnet, the whole procedure described above will be repeated starting from establishing the TR path. 3.2 Problems for the NSIS support of RO The RO procedures involve the change of data path without the MN moving, i.e. no handover. Therefore, some of the current NSIS process may not work properly with this scenario. The Applicability draft [5] discussed briefly on this issue, but stopped short without offering details. The relationship between a RO path and TR path is special. They are separate data paths, with different characteristics, but they are also related since the MN is actually at the same location using the same CoA. The MN could communicate with the CN using different path at different stage of the session. Moreover, when the MN moves to a new location, the TR path will need to be used again. Therefore, the change of the data path in RO procedure is different from that resulted from a MN changing its point of attachment. The NSIS signaling for the TR path and RO path of the same session may have overlapped sections. Double resource reservation over these paths needs to be avoided. To this end, mechanisms similar to those for a MN handover could be used. However, unlike path change caused by MN's movement, MN is still reachable to CN via the TR path in RO case. TR path would be reused when RO path is aborted, or MN moves to a new location. Therefore reservation state for the old path, i.e. TR path, may have to be kept. Simultaneously, reserved resource for TR path may have to be reduced to not waste limited resources. Signaling management for each path would also need to be done separately, depending on control policies. Reservation state handling for TR path and RO path requires more flexibility than state handling for path changes caused by MN's move or re-routing. To realize flexible operation, it is required that every NSIS Node could differentiate RO path and TR path reservation state with NSIS protocols. For example, from a NSIS message, the node should be able to know if the signaling is for a TR path or a RO path, and to know if there is an existing state for a TR or RO path of the same session. As described in section 3.1, the TR path and RO path T. Sanda et al. Expires - April 2005 [Page 5] Internet-Draft Path type support for NSIS signaling October 2004 are handled independently with current NSIS protocols. Obviously this cannot meet the requirements for RO support. In summary, current NSIS protocol design cannot indicate the complicated relationship between TR path and RO path in the signaling. Since the RO is common for a MIPv6 enable network, NSIS protocols cannot support mobility properly without a solution to this problem. With the NSIS signaling, state handling depends mainly on the Session Identifier (Session ID) and the Flow Identifiers (Flow IDs) [3,4]. Therefore, to accommodate the RO procedure, proper selection of the two identifiers is crucial. However, with the current protocol design, these identifiers only provide routing information. Therefore, a combination of additional fields with the identifiers is necessary to carry the RO relevant information. In the following section, details of the identifier manipulation to support RO are discussed. 4. Identifiers for TR path and RO path signaling As discussed in Section 3, it would be required that QoS states for TR path and RO path at the same location and at the different location be treated differently. Figure 2 shows one example scenario of TR path and RO path with MN A's movement. Each QNE along overlapping sections needs to recognize each path and decide on how to operate the states, e.g. which paths are required to be removed or refreshed. Current NSIS protocols make use of two identifiers, Session ID and Flow ID, for the session state management. Selection of the identifier values decides state handling ability of QNEs. When identifiers are manipulated as specified by the current NSIS protocols, there are two ways to differentiate the TR and RO paths. The signaling messages for the TR and RO paths could use the same Session ID or different Session IDs. This section discusses in detail the issues and problems for each of the methods. T. Sanda et al. Expires - April 2005 [Page 6] Internet-Draft Path type support for NSIS signaling October 2004 +----+x x x x x x x x x x x x+----+x x x x+----+x x x x+----+ | HA |z z z z z z z z z z z z|QNE3|z z z z|QNE4|z z z z|CN B| | | y| |y y y y| |y y y y| | +----+ y +----+ +----+w w w w+----+ x z y w x z y w +----+ y w |QNE2|z y w | | z y w +----+ y z w x y z w x y z w +----+ y z +----+ |QNE1|y z |QNE5| | | z| | +----+ +----+ x y z w x y z w +----+ +----+ |AR1 | |AR2 | +----+ +----+ x y z w x y z w +----+ +----+ |MN A| |MN A| | | ---------------> | | +----+ +----+ location1 location2 xxxxx TR path at Location1 yyyyy RO path at Location1 zzzzz TR path at Location2 wwwww RO path at Location2 Figure2: An example of TR path and RO path with MN's movement 4.1 Utilizing different Session IDs A possible method for TR and RO path handling is to use different Session IDs to identify TR path and RO path. In this case, each path will be treated as an independent session and would be managed separately. For example in Figure 2, the TR path (between CN B and MN A at location1, i.e. path x) and the RO path (between CN B and MN A at location1, i.e. path y) can be differentiated by QNEs easily since the Session IDs used are different. Differentiations between TR paths at different locations (e.g. path x and path z), and RO paths at different locations (e.g. path y and path w) are also easy because corresponding Flow ID changes when MN moves. T. Sanda et al. Expires - April 2005 [Page 7] Internet-Draft Path type support for NSIS signaling October 2004 Another advantage would be to ease treatment of QoS states for TR path and RO path independently and flexibly. For example, MN can allocate 70% resources for RO path and 30% for the TR path. However, using different Flow IDs for TR and RO paths means a session binding function is needed to associate the two paths at the same location to avoid double reservation. Since Session ID is a large random number, session binding information would make signaling message and state information heavy. In addition, each path's attribute, e.g. it is TR or RO, is only known to the MN. Therefore, only MN could initiate the session binding or flexible operation for each path. This reduces the flexibility of the NSIS protocols, and adds burden to MN that has limited resources, e.g. computation power and memory. Besides, anther problem of this method is that two (or more) Session IDs are used for one session. It is a waste of the Session ID space, and requires MN to implement special processing logic. 4.2 Utilizing the same Session ID Another way for the NSIS signaling is to use the same Session ID for both the TR path and RO path. In this case, there are also two possible solutions based on the Flow ID utilization. As discussed in draft [3,5], a Flow ID will be generated based on the protocol address information. For the RO path, it is quite obvious that the Flow ID would be based on the CoA of the MN and the CN address. However for a TR path there are tunnels involved between MN and HA. Therefore, several combinations are possible for the use of Flow IDs to represent the paths in NSIS signaling. Generally, there are three options: - Flow ID based on HoA of MN and CN address for the whole TR path; - Combination of Flow ID based on CoA of MN and HA address for tunneled section and Flow ID based on HoA of MN and CN address for section between HA and CN; - Flow ID based on CoA of MN and CN address for the whole TR path. Details of each possibility are presented below. 4.2.1 Flow ID based on HoA and CN address for whole TR path Based on the packet encapsulation presented in Figure 1, the Home Address of the MN (HoA-A) and the CN's address (CN-B) are involved in the TR path communication. Therefore, this address pair could be used for the TR path signaling. Similarly, as shown in Figure 1, the Flow ID for the RO path would be based on the CoA of MN (CoA-C) and CN's address (CN-B). Therefore, it results in different Flow IDs for TR T. Sanda et al. Expires - April 2005 [Page 8] Internet-Draft Path type support for NSIS signaling October 2004 and RO paths. This way, the TR path and RO path could be differentiated. However it cannot provide the information that these two paths are at the same location. For example, in Figure 2, NSIS state for path x and path y would have different Flow IDs. When QoS state for path y is installed, QNE1 and QNE3 would consider MN A performed a handover as the Flow IDs are different but the Session IDs are the same. Therefore the QNEs would try to initiate the release of old path state. As mentioned above, the TR path may not need to be deleted after the RO path is up. With current NSIS protocols, to keep the state for path x, No_replace flag [4] could be used. However this flag cannot be used for a flexible operation such as reducing reserved QoS resources along path x. Furthermore, when MN moves to location2 and QoS state for path z is installed, QNE1 would consider that the data path is changed by re- routing because Session ID and Flow ID of path z are the same as path x. This confusion may not cause big problem since the path x from QNE2 to CN B would be simply refreshed to path z, and path z from MN at location1 to QNE 2 would be released. However, when QoS state for path w is installed, QNE4 has no way to know which path should be released and which path should be kept. MN may be able to send a list of Flow IDs to be managed with the message, but it would cause large signaling overhead. In the NSIS signaling, the detection of the path changes relies on the monitoring of Flow ID variations. In this case, the HoA of MN (HoA-A) is used to the Flow ID for the TR path. It results in a constant Flow ID, since the HoA-A never changes. Therefore, such a Flow ID cannot reflect MN's path change. 4.2.2 Different Flow IDs for different section of TR path As shown in Figure 1, there TR path has two types of encapsulations. A bi-direction tunnel is used between MN and HA. Therefore, different Flow IDs could be used for the signaling of these two different sections of the TR path. For the tunnel section (from MN to HA), Flow ID could be derived based on the CoA of the MN and the HA's address. On the other hand, for the second section (from HA to CN), Flow ID could be derived based on the HoA of the MN and the CN's address. With this type of scheme, the confusion for TR path change detection could be avoided. However, it only applies for the tunneled section, where the Flow ID is based on the CoA of the MN. For the section between HA and CN, the same confusion exists. T. Sanda et al. Expires - April 2005 [Page 9] Internet-Draft Path type support for NSIS signaling October 2004 The rest of the problems mentioned in section 4.2.1 all apply to this method as well. To indicate the binding relationship between TR path and RO path still remains as a challenge. Besides the above, the use of different Flow IDs for different sections of TR path also increases the state management cost on NSIS aware nodes, especially the Home Agent of MN. To go one step further with this method, signaling for the tunneled TR section could be carried out as another session as described in [8]. But, it shares the same problems as mentioned above. 4.2.3 Flow ID based on CoA of MN and CN address for TR path As discussed in section 4.2.1, to promptly detect path change for TR path, the Flow ID for TR path should also be based on CoA of the MN and the CN address. Obviously, it results in the same Flow ID for the TR and RO path based on current NSIS protocol [3]. When the same Flow ID is used, it clearly shows the binding between the TR and RO paths, i.e. these two paths are at the same location. However, this does not provide ways to differentiate the TR path and RO path. And therefore in Figure 2, QNE1 and QNE3 would take it as a network re-routing when it receives signaling for path y after the state for path x is established, since the same Flow ID is used but different interfaces/previous hops are involved. Therefore, extra information bits are needed in the signaling message to distinguish the paths. 5. Solution Requirement Analysis The method in section 4.1 (utilize different Session ID) would not be feasible because it would cause signaling overhead and requires special logic, e.g. session binding. It adds burden to both the MN and NSIS aware nodes. Therefore, it is not a proper solution to the problem. This section discusses in detail the issues for method mentioned in section 4.2. 5.1 Requirements for the RO procedure support For the methods mentioned in Section 4.2, the general problem is regarding how the TR and RO paths could be distinguished. Since the Flow ID is not able to indicate that, some extra information element is necessary. One possible method is to include a path information element in the NSIS signaling message, e.g. a Path type ID. This ID indicates whether the path is TR path or RO path For example, in the case of QoS NSLP signaling, a Path Type ID is included in the RESERVE message and is stored in a state of QNE with T. Sanda et al. Expires - April 2005 [Page 10] Internet-Draft Path type support for NSIS signaling October 2004 Flow ID and Session ID. Path Type ID could be codes, for example, "0x01" is corresponding to TR path and "0x02" is corresponding to RO path. Since it is short, certain reserved fields of NSIS message header could be used to carry it. Therefore, minimum overhead would be added to the signaling. MN can decide Path Type ID by the information from MIP layer, e.g. receiving Binding ACK message, and then set the Path Type ID in RESERVE message. By supporting Path Type ID, the problem in section 4.2 could be solved. When the same Flow ID is used for TR path and RO path (the case in 4.2.3), QNEs shown in Figure 2 could explicitly know that states for path x and path z are for TR paths, and path y and path w are for RO paths. Therefore, when state for path y is installed, QNE1 and QNE3 could distinguish this from a path change caused by re-routing. In addition to this, flexible operation in intermediate QNEs is achieved. Even when MN A moves to location 2 and state installation for new paths is performed, QNEs along overlapping section could recognize which path should be released and which path should be kept by comparing Path Type ID and Flow ID. Regarding to different Flow ID case (the case in 4.2.1 and 4.2.2), the same method is applicable. When states for path x followed by path y are installed, QNE1 and QNE3 could distinguish this path change from path change caused by MN's movement. Flexible operation for these two paths is also possible. Even when MN A moves to location 2, QNEs could still distinguish the old path and new path by comparing Path Type ID and Flow ID. However, the method to explicitly associate TR path and RO path at the same location may be required. For supporting this functionality, an object to decide MN's location, such as mobility_event_counter mentioned in Applicability Statement draft [5] could be useful. 5.2 Other requirements relevant to NSIS identifiers 5.2.1 Use of packet classifier vs. Flow ID In the current NSIS protocol [3, 4], it is suggesting that the Flow ID should contain the data packet routing information. Furthermore, in the QSpec draft [7], it is suggested that the Flow ID information would be used for classifying the data traffic. However, this may cause problems in a complicated scenario. A few examples are given below: a) In the section 4.2.1 of QSpec Draft [7], scheduling of reservations ahead of time is mentioned. The full Flow ID may not be available at the reservation stage in this scenario. This means that the identifier to be used for reservation is a different object from T. Sanda et al. Expires - April 2005 [Page 11] Internet-Draft Path type support for NSIS signaling October 2004 the actual packet classifier. If the Flow ID is employed as the data packet classifier, the state installed using the incomplete Flow ID is not usable. Therefore, the separation of Flow ID from data packet classifier information is necessary. b) Nowadays, a communication usually contains several threads, e.g. using the SmartFTP or, Download Accelerator, in which usually 3 to 5 threads will be opened simultaneously for downloading a file to boost up the speed. Therefore, for the same flow, several ports will be used for the downloading. In this case, the Flow ID will not be able to represent the multiple threads for the identical flow. For example, the user wants to allocate certain QoS for a FTP/streaming session, there could be several ports using the same address involved, whereas, the Flow ID could indicate only one port. This means that the current use of the Flow ID to indicate the packet classifier does not support the most commonly used applications nowadays. Although wildcarding is mentioned in [3], it means only one session could be supported between any two nodes. For example, if the user were accessing FTP service from a server using ports 10001 and 10002, and accessing video streaming from the same server using port 10003 and 1004, wildcarding would not be able to support separation of the two sessions. Thus, the classifier that includes the port number should be separated from Flow ID. c) For the RO signaling support mentioned in section 4.2.3, Flow ID could not be used as packet classifier because header information for TR path is not the same as what is used to generate Flow ID. Therefore, packet classifier should be considered separately from Flow ID. Usually, the data packet classifying information depends on the NSLP application, e.g. the QoS Model used. Therefore, it would be proper to include that in the NSLP layer, e.g. in the QSpec. Some object like FlowSpec would be useful in QSpec to indicate the actual packet filter information. 6. Security Considerations Security should be considered in the NTLP/NSLP specifications as an integrated part. Specific issues in Route Optimization case will be essentially covered by the Route Optimization security in Mobile IPv6 [6]. Future version of this draft would discuss the relevant security requirements for the solutions in detail. T. Sanda et al. Expires - April 2005 [Page 12] Internet-Draft Path type support for NSIS signaling October 2004 7. Conclusions This draft discussed potential problems related to NSIS QoS state management for path changes caused by Mobile IP RO procedures. As one possible solution, Path Type ID was introduced so that QNEs could perform flexible state management for each path. Some other requirements to solve the problems were also described. References 1. "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, March 1997, 2. R. Hancock, et al. "Next Steps in Signaling: Framework" draft- ietf-nsis-fw-06, (work in progress) July 2004 3. H. Schulzrinne, R. Hancock, "GIMPS: General Internet Messaging Protocol for Signaling", draft-ietf-nsis-ntlp-03, (work in progress) July 2004 4. Sven Van den Bosch, et al. "NSLP for Quality-of-Service Signaling", draft-ietf-nsis-qos-nslp-04, (work in progress) July 2004 5. S. Lee, et al. "Applicability Statement of NSIS Protocol in Mobile Environments", draft-manyfolks-signaling-protocol- mobility-01.txt, (Work in progress) July 2004 6. D. Johnson, C. Perkins, J. Arkko "Mobility Support in IPv6", June 2004, 7. Jerry Ash, Attila bader, Cornelia Kappler "QoS-NSLP QSpec Template", draft-ietf-nsis-qspec-00, (work in progress) September 2004 8. F. Baker, et al. "Aggregation of RSVP for IPv4 and IPv6 Reservations", September 2001, Author's Addresses T. Sanda et al. Expires - April 2005 [Page 13] Internet-Draft Path type support for NSIS signaling October 2004 Takako Sanda Matsushita Electric Industrial Co., Ltd. (Panasonic) 5-3, Hikarino-oka, Yokosuka City, Kanagawa 239-0847, Japan Phone: (+81) 46 840 5764 Email: sanda.takako@jp.panasonic.com Toyoki Ue Matsushita Electric Industrial Co., Ltd. (Panasonic) 5-3, Hikarino-oka, Yokosuka City, Kanagawa 239-0847, Japan Phone: (+81) 46 840 5816 Email: ue.toyoki@jp.panasonic.com Hong Cheng Panasonic Singapore Laboratories Blk 1022 TaiSeng Ave, #06-3530 TaiSeng Ind. Est. Singapore 534415 Phone: (+65) 65505477 Email : hcheng@psl.com.sg T. Sanda et al. Expires - April 2005 [Page 14] Internet-Draft Path type support for NSIS signaling October 2004 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. 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. 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. T. Sanda et al. Expires - April 2005 [Page 15]