Internet Draft Jun Kyun Choi Document: draft-choi-ipv6-signaling-req-ntlp-00.txt Hyun Hye Lee Expiration Date: December 2003 Gyu Myoung Lee ICU Hyoung Jun Kim Ki Shik Park ETRI Tae-Gon Noh June-Koo Rhee Samsung AIT July 2003 Requirements for IPv6 Signaling as NTLP Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC-2026. 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. Abstract In this draft, we present the features of IPv6 protocol related to NSIS Transport Layer Protocol (NTLP) and requirements for IPv6 signaling as NTLP in different Internet transport infrastructure, such as SDH/SONET switch, Optical cross-connect (OXC), ATM switch, Ethernet switch, wireless system, and router. In this framework, user data is transported via nodes in the data plane and signaling messages are routed to NEs in the control plane. We propose the new protocol, Internet Signaling Message Protocol (ISMP) for carrying signaling messages. And other delivering methods of signaling messages in IPv6 network are also presented in appendix. Choi, et. al. [Page 1] Requirements for IPv6 Signaling as NTLP July 2003 Conventions 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. Table of Contents 1. Introduction.....................................................3 1.1. Existing QoS Signaling Protocols and NSIS Activities...........3 1.2. Motivation of IPv6 Signaling as NTLP...........................4 2. Overview of IPv6 Signaling Concept and Features..................4 2.1. Signaling Framework............................................4 2.2. The Features of IPv6 Protocol related to NTLP..................5 3. Requirements for IPv6 Signaling as NTLP..........................6 3.1. Resource Reservation...........................................6 3.2. Flow Label Distribution........................................6 3.3. Backward Compatibility.........................................6 3.4. Easy to implement..............................................6 3.5. Scalability....................................................7 3.6. Mobility Support...............................................7 3.7. Signaling Interworking.........................................7 3.7.1. Signaling Interworking between IPv6 and IPv4.................7 3.7.2. Signaling Interworking between IPv6 and Existing Telco Network ....................................................................9 3.7.3. Support of Domain Service Model on Optical Transport Network10 4. IPv6 Next Header for Signaling..................................11 5. IANA Considerations.............................................12 6. Security Considerations.........................................12 Appendix. The delivering Methods for Signaling Messages in IPv6 Network............................................................13 7. References......................................................15 8. Author's Addresses..............................................17 Choi, et. al. [Page 2] Requirements for IPv6 Signaling as NTLP July 2003 1. Introduction There is the transition of the Internet from IPv4 to IPv6. IPv6 is designed to run well on high performance networks (e.g., Gigabit Ethernet, OXC, ATM, etc.) and at the same time still be efficient for low bandwidth networks (e.g., wireless network). In addition, it provides a platform for new Internet functionality that will be required in the near future. The architecture described in this draft clearly separates the control plane and the data plane. In addition, control plane is made of two signaling protocol layers: NSIS Transport Layer Protocol (NTLP) and NSIS Signaling Layer Protocol (NSLP) in [NSISFW]. User data is transported via nodes in the data plane and signaling messages are routed to NEs in the control plane. This path-decoupled signaling take advantage of reusing existing transport devices whose data plan cannot recognize the IP header and having flexibility in NE deployment. Actually, IPv6 has many native features to support QoS and other capabilities for the emerged network, such as Hop-by-Hop Option header, Routing Option header, and Destination Option header as described in [RFC1883]. We will describe about that in section 2.2. By utilizing this IPv6 features, we can assist the existing signaling protocols without modifying themselves and it can provide additional features to NTLP. On the other hand, one who doesn't care of the modification of the existing signaling protocols may modify slightly the existing signaling mechanisms to adopt IPv6 signaling as NTLP. We present requirements for IPv6 signaling as NTLP in section 3. Also we will propose the methods those modify existing signaling protocol specifications to make use of the power of IPv6 function to the signaling mechanisms in section 4. And other delivering methods of signaling messages in IPv6 network are also presented in appendix. 1.1. Existing QoS Signaling Protocols and NSIS Activities A number of different QoS mechanisms have been developed by the IETF. Usually the QoS mechanisms are supported in the IP layer or the Transport layer (e.g., TCP or UDP). We can regard following QoS signaling protocols. o RSVP-TE(including RSVP-TE extension for GMPLS [RFC3473]) RSVP-TE [RFC3209] specifies the extension to RSVP for establishing traffic engineered path. Both RSVP [RFC2210] and RSVP-TE are implemented on the IP layer. RSVP is defined to support QoS in IP network with fine granularity, but this leads the scalability problems. RSVP-TE has some additional concepts, like label distribution, aggregated flow, and explicit route. Choi, et. al. [Page 3] Requirements for IPv6 Signaling as NTLP July 2003 o CR-LDP(including CR-LDP extension for GMPLS [RFC3472]) CR-LDP [RFC3212], from LDP, use the TCP(and UDP) layer instead of IP layer in RSVP-TE. So this signaling protocol uses the features of TCP protocol. The NSIS Working Group focuses on providing end-to-end signaling across different network environment and develops the requirements, architecture and protocols for the next IETF steps on signaling. They defines requirements for signaling in [NSISREQ], analyzes existing protocols for signaling the QoS requirements of flows to nodes in an IP network in [NSISANALYSIS], and provides a model for the network entities that take part in signaling in [NSISFW]. 1.2. Motivation of IPv6 Signaling as NTLP Carriers are currently migrating to a consolidated single network based on IP technology called the Next-Generation Network (NGN) and so future transport networks is expected to be made of different transport elements such as SDH/SONET switch, Ethernet switch, ATM switch, OXC, wireless system, router, etc. NGN clearly separate control functions from transport functions, both service control functions and network resource control functions. And the current Internet is transiting from IPv4 to IPv6. We cannot predict the deployment step of IPv6 in real environment. But we can assume that the mobile access network is the major application of IPv6. This is mainly due to the large address space of IPv6. Also we can predict that the large percentile of packets in that network will be carried real time traffic such as voice or video. It is worth to lay emphasis on these applications will heavily depend on the QoS mechanism in IPv6 networks. But, existing signaling protocols concern only on delivery signaling message over IPv4 network as we see section 1.1. In signaling point of view, IPv6 protocol has many features related to QoS and other capabilities. By utilizing IPv6 features, such as ease of defining explicit route, flow labeling capability and improved support for extensions and options like Hop-by-Hop Option header or Destination Option header, we can improve the efficiency of IPv6 networks and we can enjoy that without modifying the existing signaling protocols. 2. Overview of IPv6 Signaling Concept and Features 2.1. Signaling Framework Figure 1 shows a diagram of signaling framework for future Internet based on different transport network. The architecture clearly Choi, et. al. [Page 4] Requirements for IPv6 Signaling as NTLP July 2003 separates the control plane and the data plane. In addition, control plane is made of two signaling protocol layers: NSIS Transport Layer Protocol (NTLP) and NSIS Signaling Layer Protocol (NSLP) in [NSISFW]. Data flow messages are transported from sender to receiver via node N1, N2 and N3 in the data plane and signaling messages are routed to NEs in the control plane. Node in data plane can be a different transport device such as SDH/SONET switch, Optical cross-connect (OXC), ATM switch, Ethernet switch, wireless system, router, etc. This path-decoupled signaling take advantage of reusing existing transport devices whose data plan cannot recognize the IP header and having flexibility in NE deployment. +--------+ +--------+ +--------+ +--------+ +--------+ | NE | | NE | | NE | | NE | | NE | | +----+ | | +----+ | | +----+ | | +----+ | | +----+ | | |NSLP| | | |NSLP| | | |NSLP| | | |NSLP| | | |NSLP| | | +----+ | | +----+ | | +----+ | | +----+ | | +----+ | | || |====| || |====| || |====| || |====| || | | +----+ | | +----+ | | +----+ | | +----+ | | +----+ | | |NTLP| | | |NTLP| | | |NTLP| | | |NTLP| | | |NTLP| | | +----+ | | +----+ | | +----+ | | +----+ | | +----+ | +--------+ +--------+ +--------+ +--------+ +--------+ Control plane --------------------------------------------------------------------- Data plane +--------+ +--------+ +--------+ +--------+ +-------- + | Sender |--->| N1 |--->| N2 |--->| N3 |--->| Receiver| | App | | | | | | | | App | +--------+ +--------+ +--------+ +--------+ +---------+ Appp = Application N1, N2, N3 = node ==== = Signaling Messages ---> = Data flow Messages Figure 1. Signaling framework 2.2. The Features of IPv6 Protocol related to NTLP To validate the further discussion, we must describe the native features of IPv6 protocol related to NTLP. o Priority Flow Control Each node has many flows with different priority of various data rates and QoS requirements. These flows are classified and scheduled Choi, et. al. [Page 5] Requirements for IPv6 Signaling as NTLP July 2003 with the capability of making intelligent decisions on how resource allocation SHOULD be controlled. The Priority filed in IPv6 header [RFC1883] enables a source to identify the desired delivery priority of its packets, relative to other packets form the same source. o Explicit Route In IPv6 specification [RFC1883], there is a route extension header to use explicit route. Explicit route is important for traffic engineering in IPv6 networks. There is already ROUTE object in RSVP- TE specification [RFC3209]. In the case of CR-LDP [RFC3212], some TLVs are defined to be used for this purpose. We discuss the explicit route setup for interworking with MPLS signaling in IPv6 network. (See section 4.2) o Flow Identification. In IPv6 flow label specification [FLOWLABEL], flow identification includes the 3-tuple of the Flow Label and the Source and Destination Address fields. Flow state is created and stored by the NEs and packet classification is done by the node on data plane. 3. Requirements for IPv6 Signaling as NTLP This section defines requirements for IPv6 signaling as NTLP. 3.1. Resource Reservation The key role of signaling protocol is to allocate and reserve the network resource for the purpose of meeting end-to-end QoS requirements along the entire path. The IPv6 signaling protocol MUST be able to deal with such resource allocation request. 3.2. Flow Label Distribution To make use of flow label field of IPv6 basic header and identify the flow label between the nodes on specific data path, label-binding information SHOULD be delivered between the related nodes. The related nodes are on the specific path of the flow. Label value is only meaningful between a pair of nodes. And the label value is predetermined before forwarding data packet along the path. 3.3. Backward Compatibility The existing signaling protocols such as RSVP, RSVP-TE, CR-LDP and so on are implemented in IPv4 network. These signaling protocols MUST be operated in IPv6 network. Therefore, they MUST support backward compatibility for operating both IPv6 and IPv4. 3.4. Easy to implement Choi, et. al. [Page 6] Requirements for IPv6 Signaling as NTLP July 2003 There are two aspects related with this issue. First, we can consider the compatibility of the new signaling with existing signaling. So the implementation can be done with minimum modification of previous architecture and components. Second we can omit some functions of previous signaling so that we just make a light-weight signaling mechanism. We are still studying about this carefully because it makes some effects with other various factors such like the capabilities of this new signaling and the signaling translation between two heterogeneous AS's. We can think above two factors simultaneously and SHOULD make some trade-off. 3.5. Scalability The performance of the signaling protocol SHOULD not largely depend on the scale of the network to which IPv6 is applied (e.g. the number of nodes, the number of physical links etc). The signaling function SHOULD keep constant performance as much as possible regardless of network size. Aggregating flows can reduce resource allocation and runtime management overhead. 3.6. Mobility Support To provide the QoS in mobile environment, we SHOLD consider the mobility of nodes and dynamic behavior of related flows. In signaling, we are concerning two problems. First the flow management can be considered with per aggregated flow or per flow. In some point, snapshot of network can be described with many aggregated flows and related QoS management. But as time goes, some flow of mobile node departs one aggregated flow and join the other aggregated flow. Second the support of micro mobility issues. To make use of old flow related resources as much as possible, we should define Nearest Common Router (NCR) and provide the finding mechanism. This work is under working. We just consider the need of modification or adaptation of that mechanism in our work. 3.7. Signaling Interworking Most of the signaling protocols are based on the underlying network infrastructure, i.e. IP networks, but they don't depend on the minor version of the network. For example, one signaling protocol designed for the IPv4 network can be used in IPv6 network without modifying the specification of the signaling mechanism. Rather than to do like that, the signaling protocol adopt itself to the different version of network implementation by defining option fields like IP version information field and related information like IPv4 addresses (32 bits) or IPv6 addresses (128 bits). Therefore, Signaling in IPv6 network MUST consider the interworking with IPv4 network and existing wireline/wireless telco network. 3.7.1. Signaling Interworking between IPv6 and IPv4 Choi, et. al. [Page 7] Requirements for IPv6 Signaling as NTLP July 2003 To be gradually deployed, we can consider the situation of mixed nodes that some implement the IPv6 signaling and others implement the IPv4 signaling. Deployment point of view, we consider three stages of evolution scenarios. - first stage (stage 1): IPv4 ocean and IPv6 island - second stage (stage 2): IPv6 ocean and IPv4 island - third stage (stage 3): IPv6 ocean and IPv6 island In first stage shown in Figure 2, MPLS-based core network (e.g., IPv4 ocean) and IPv6 access network (e.g., IPv6 island) is deployed. In this environment, core signaling such as RSVP-TE and CR-LDP is used in IPv4 ocean and access signaling such as RSVP and RSVP-TE is used in IPv6 island. To support end-to-end QoS signaling, these protocols SHOUD perform the mapping of IPv6 with IPv4. Flow label information of IPv6 header is translated to FEC(Forwarding Equivalent Class) [RFC3031] information of MPLS. For this reason, signaling interworking function is needed. Using this QoS signaling, flow information is transmitted unchanged from source to destination and the required resource is reserved and end to end path is established. +-------------+ +---------------+ +-------------+ | IPv6 island |-------| IPv4 ocean |-------| IPv6 island | | |-------| (MPLS) |-------| | +-------------+ +---------------+ +-------------+ Flow Label -- mapping -- FEC -- mapping -- Flow Label |<----------->| |<------------->| |<----------->| RSVP/RSVP-TE RSVP-TE/CR-LDP RSVP/RSVP-TE (Access signaling) (Core signaling) (Access signaling) |<--------------------------------------------------------->| end-to-end QoS signaling Figure 2. Signaling mapping (stage 1) In second stage shown in Figure 3, IPv6 network will dominate over IP4 network. This network is composed of IPv6-based core network (e.g., IPv6 ocean) and IPv4-based access network (e.g., IPv4 island). The existing IPv4 network is operated in MPLS. In this environment, core signaling such as RSVP-TE and CR-LDP is used in IPv6 ocean and access signaling such as RSVP and RSVP-TE is used in IPv4 island. FEC information of IPv4 is translated to flow label information of IPv6. +-------------+ +---------------+ +-------------+ | IPv4 island |-------| IPv6 ocean |-------| IPv4 island | | (MPLS) |-------| |-------| (MPLS) | Choi, et. al. [Page 8] Requirements for IPv6 Signaling as NTLP July 2003 +-------------+ +---------------+ +-------------+ FEC -- mapping -- Flow Label -- mapping -- FEC |<----------->| |<------------->| |<----------->| RSVP/RSVP-TE RSVP-TE/CR-LDP RSVP/RSVP-TE (Access signaling) (Core signaling) (Access signaling) |<--------------------------------------------------------->| end-to-end QoS signaling Figure 3. Signaling mapping (stage 2) In third stage shown in Figure 4, IPv6 protocol is implemented both core network (e.g., IPv6 ocean) and access network (e.g., IPv6 island). Signaling protocol like RSVP-TE MAY be used without signaling translation. +-------------+ +---------------+ +-------------+ | IPv6 island |-------| IPv6 ocean |-------| IPv6 island | +-------------+ +---------------+ +-------------+ Flow Label - mapping -- Flow Label -- mapping - Flow Label |<----------->| |<------------->| |<----------->| RSVP/RSVP-TE RSVP-TE/CR-LDP RSVP/RSVP-TE (Access signaling) (Core signaling) (Access signaling) |<--------------------------------------------------------->| end-to-end QoS signaling Figure 4. Signaling mapping (stage 3) 3.7.2. Signaling Interworking between IPv6 and Existing Telco Network We SHOULD consider the signaling interworking between IPv6 and existing Telco network. Telco network may be composed of PSTN, cellular, IMT2000 network and so on. Using signaling, the physical/logical circuit is established. To support end-to-end QoS signaling, we consider two cases (see Figure 5-6). Both cases SHOUD perform the mapping of flow label and phsyiscal/logical circuit. +-------------+ +-----------------+ +-------------+ | IPv6 Client |------| PSTN/Cellular/ |------| IPv6 Client | | Network |------| IMT2000-Network |------| Network | +-------------+ +-----------------+ +-------------+ Flow label - mapping - physical/logical- mapping - Flow Label Circuit |<----------->| |<--------------->| |<----------->| Choi, et. al. [Page 9] Requirements for IPv6 Signaling as NTLP July 2003 Acess Signaling Telco Signaling Access Signaling |<--------------------------------------------------------->| end-to-end QoS signaling Figure 5. Signaling mapping for Telco network (case 1) +-------------+ +-----------------+ +-------------+ | PSTN |------| IPv6 |------| Cellular | | ISDN |------| Ocean |------| INT-2000 | +-------------+ +-----------------+ +-------------+ Physical/ -- mapping - Flow Label-- mapping - Physical/ Logical Circuit Logical Circuit |<----------->| |<--------------->| |<----------->| Telephone Signaling Core Signaling Cellular/ IMT-2000 Signaling |<--------------------------------------------------------->| end-to-end QoS signaling Figure 6. Signaling mapping for Telco network (case 2) 3.7.3. Support of Domain Service Model on Optical Transport Network IPv6 network SHOULD support the signaling interworking with optical transport network. The optical transport network control plane reuse IP-based protocols that are based on the signaling and routing mechanisms developed for IP traffic engineering applications. Core signaling such as Optical-UNI (User-Network-Interface) [UNI] and GMPLS signaling (RSVP-TE extensions [RFC3473], CR-LDP extensions [RFC3472]) are used in domain service model on optical transport network (see Figure 6). To support end-to-end QoS signaling, these protocols SHOULD perform the interworking with access signaling of IPv6 client network. Flow label information of IPv6 is translated to optical label information. +-------------+ +-----------------+ +-------------+ | IPv6 Client |------|Optical Transport|------| IPv6 Client | | Network |------| Network |------| Network | +-------------+ +-----------------+ +-------------+ Flow label - mapping -- Optical Label -- mapping - Flow Label |<----------->| |<--------------->| |<----------->| Acess Signaling O-UNI, GMPLS Signaling Access Signaling |<--------------------------------------------------------->| end-to-end QoS signaling Figure 7. Signaling mapping for optical network Choi, et. al. [Page 10] Requirements for IPv6 Signaling as NTLP July 2003 4. IPv6 Next Header for Signaling To delivery signaling messages in IPv6 networks, we propose method using the new Next Header value for signaling message and define this new protocol as Internet Signaling Message Protocol (ISMP). Message body includes signaling messages like RSVP, RSVP-TE, CR-LDP. Every signaling message is preceded by an IPv6 header or by more IPv6 extension headers. The signaling message is identified by a Next Header value in the immediately preceding header. The signaling messages have the following general format: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Version| Traffic Class | Flow Label | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Payload Length | Next Header | Hop Limit | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Source Address + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Destination Address + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + | ISMP Message Body | + (signaling message) + Version 4-bit Internet Protocol version number = 6. Traffic Class 8-bit traffic class field. Flow Label 20-bit flow label. Payload Length 16-bit unsigned integer. Length of the IPv6 payload, i.e., the rest of the packet following this IPv6 header, in octets Next Header 8-bit selector. Identifies the type of signaling message immediately following the Choi, et. al. [Page 11] Requirements for IPv6 Signaling as NTLP July 2003 IPv6 header. Uses the same values as the IPv4 Protocol field [RFC1700] Hop Limit 8-bit unsigned integer. Decremented by 1 by each node that forwards the packet. The packet is discarded if Hop Limit is decremented to zero. Source Address 128-bit address of the originator of the packet. Destination Address 128-bit address of the intended recipient of the packet (possibly not the ultimate recipient, if a Routing header is present). For this method, we MUST assign the new Next Header value of IPv6 header. Currently, RSVP is already assigned the value 46 decimal in [RFC1700]. For example, if the Next Header value of IPv6 header is 46 decimal the following ISMP message is RSVP message. The Next Header value of other unassigned signaling messages SHOULD be assigned by IANA. This method is very simple because of no additional extension header. Therefore, the complexity of processing is reduced but this new function MUST be implemented within IPv6 header. Note: the signaling protocols, like SIP (Session Initiation Protocol) [RFC3372], that are used for end-to-end path may use the option TLVs to indicate the presence of the signaling information. We already know that the real-time service cannot be served without support of intermediate node. If some end-to-end sessions are need to be guaranteed to their perceived QoS, the intermediate nodes those are on the path may use the information to do something related with QoS implicitly. 5. IANA Considerations The value field described in Section 3 SHOULD be registered and maintained by IANA. The New values SHOULD be to be assigned via IETF Consensus as defined in [RFC 2434]. 6. Security Considerations This document does not have any security concerns. The security requirements using this document are described in the referenced documents. Choi, et. al. [Page 12] Requirements for IPv6 Signaling as NTLP July 2003 Appendix. The delivering Methods for Signaling Messages in IPv6 Network In this section, we will describe methods of assisting existing signaling protocols in IPv6 networks via using IPv6 extension headers. 1. RSVP/RSVP-TE for IPv6 (including RSVP-TE extensions for GMPLS) IPv6 Router alert option [RFC2711] within the IPv6 Hop-by-Hop option header has the semantic "routers should examine the datagram more closely". Using this option, IPv6 datagram containing signaling messages are indicated and taken actions. The router alert option has the following format: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 0|0 0 1 0 1|0 0 0 0 0 0 1 0| Value (2 octets) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ length = 2 The first three bits of the first byte are zero and the value 5 in the remaining five bits is the Hop-by-Hop Option Type number. [RFC2460] specifies the meaning of the first three bits. By zeroing all three, this specification requires that nodes not recognizing this option type should skip over this option and continues processing the header and that the option must not change en route. There MUST only be one option of this type, regardless of value, per Hop-by-Hop header. Value: A 2 octets code in network byte order with the following values 0 Datagram contains a Multicast Listener Discovery message [RFC2710]. 1 Datagram contains RSVP message. 2 Datagram contains an Active Networks message. 3-65535 Reserved to IANA for future use. Alignment requirement: 2n+0 Values are registered and maintained by the IANA. We suggest the new value (= 3) for RSVP-TE messages. The value 3 is REQUIRED the approval of IETF and SHOULD be assigned by IANA. Other signaling messages MAY be added. In this case, the value for new signaling message SHOULD be assigned by IANA. The described method has some advantages and disadvantages. It is not necessary to implement the new protocol for signaling. The existing Choi, et. al. [Page 13] Requirements for IPv6 Signaling as NTLP July 2003 signaling message is used without change. However, all IPv6 datagram containing a signaling message MUST contain this option within the IPv6 Hop-by-Hop Option Header of such datagram. The additional option header is redundant. 2. CR-LDP for IPv6 (including CR-LDP extensions for GMPLS) In the case of RSVP-TE, if the header of a packet is indicating "This packet carries the signaling information." then the NEs can make different treatment on just only look at the IP header. On the other hand, like CR-LDP, the protocol running on the TCP(UDP) layer may also make use of the benefit that IP header already notify the existence of signaling information in the payload of IP packet. Originally in the CR-LDP protocol, the signaling information is transferred along the path per hop. If a NE sees the notification of signaling information in the IP header, it can forward the signaling packet and processing the signaling information simultaneously. So the forwarding direction of packet can be done faster than old mechanisms. Choi, et. al. [Page 14] Requirements for IPv6 Signaling as NTLP July 2003 7. References [RFC1700] J. Reynolds et al. "Assign Numbers", IETF RFC, October 1994. [RFC1633] R. Braden, et al. "Integrated Services in the Internet Architecture: an Overview", IETF RFC, June 1994 [RFC2205] R. Braden, Ed. et al. "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", IETF RFC, September 1997. [RFC2434] T. Narten, et al. "Guidelines for Writing an IANA Considerations Section in RFCs", IETF RFC, October 1998. [RFC1883] S. Deering, et al. "Internet Protocol, Version 6 (IPv6) Specification", December 1995. [RFC1885] A. Conta, et al. "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification", December 1995. [RFC2710] S. Deering, et al.. "Multicast Listener Discovery (MLD) for IPv6", October 1999 [RFC2711] C. Partridge, et al.. "IPv6 Router Alert Option", October 1999 [RFC3031] E. Rosen, et al.. "Multiprotocol Label Switching Architecture", January 2001 [RFC3036] L. Andersson, et al.. "LDP Specification", January 2001 [RFC3209] D. Awduche, et al. "RSVP-TE: Extensions to RSVP for LSP Tunnels", December 2001. [RFC3212] B. Jamoussi, et al. "Constraint-Based LSP Setup using LDP", January 2002. [RFC3472] Peter Ashwood-Smith, et al. "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Constraint-based Routed Label Distribution Protocol (CR-LDP) Extensions", January 2003. [RFC3473] Lou Berger, et al. "Generalized Multi-Protocol Label Switching (GMPLS)Signaling Resource ReserVation Protocol- Traffic Engineering (RSVP-TE) Extensions", January 2003. [RFC3372] A.Vemuri, et al. "Session Initiation Protocol for Telephones(SIP-T) : Context and Architectures", September 2002. Choi, et. al. [Page 15] Requirements for IPv6 Signaling as NTLP July 2003 [NSISFW] Ilya Freytsis et al. "Next Steps in Signaling: Framework", Internet Draft draft-ietf-nsis-fw-02.txt, March 2003. [NSISREQ] M. Brunner, "Requirements for Signaling Protocols", Internet Draft draft-ietf-nsis-req-07.txt, March 2003. [NSISANAYSIS] J. Manner, X. Fu, "Analysis of Existing Quality of Service Signaling Protocols", Internet Draft draft- ietf-nsis-signaling-analysis-01.txt, February 2003. [FlOWLABEL] J. Rajahalme, et al. "IPv6 Flow Label Specification", Internet Draft draft-ietf-ipv6-flow-label-07.txt, work in progress, April 2003. [UNI] The Optical Interworking Forum, "UNI 1.0 Signaling Specification", December 2001. Choi, et. al. [Page 16] Requirements for IPv6 Signaling as NTLP July 2003 8. Author's Addresses Jun Kyun Choi Information and Communications University (ICU) 58-4 Hwa Ahm Dong, Yusong, Taejon Korea 305-732 Phone: +82-42-866-6122 Email: jkchoi@icu.ac.kr Hyun Hye Lee Information and Communications University (ICU) 58-4 Hwa Ahm Dong, Yusong, Taejon Korea 305-732 Phone: +82-42-866-6182 Email: blueming80@icu.ac.kr Gyu Myoung Lee Information and Communications University (ICU) 58-4 Hwa Ahm Dong, Yusong, Taejon Korea 305-732 Phone: +82-42-866-6231 Email: gmlee@icu.ac.kr Hyoung Jun Kim Electronics and Telecommunications Research Institute (ETRI) 161 Ka Jong-Dong, Yusong-Gu, Taejon Korea 305-600 Phone: +82-42-860-6576 E-mail: khj@etri.re.kr Ki Shik Park Electronics and Telecommunications Research Institute (ETRI) 161 Ka Jong-Dong, Yusong-Gu, Taejon Korea 305-600 Phone: +82-42-860-6041 E-mail: kipark@etri.re.kr Tae-Gon Noh Samsung Advanced Institute of Technology (Samsung AIT) P.O. Box 111, Suwon, Kyoungki Korea 440-600 Phone: +82-31-280-9621 Email: tgnoh@samsung.com June-Koo Rhee Samsung Advanced Institute of Technology (Samsung AIT) P.O. Box 111, Suwon, Kyoungki Korea 440-600 Phone: +82-31-280-8193 Choi, et. al. [Page 17] Requirements for IPv6 Signaling as NTLP July 2003 Email: jk.rhee@samsung.com Document: draft-choi-ipv6-signaling-req-ntlp-00.txt Expiration Date: December 2003 Choi, et. al. [Page 18]