Internet Draft Jun Kyun Choi Document: draft-choi-ipv6-signaling-01.txt Gyu Myoung Lee Expiration Date: August 2002 Ki Young Jung ICU February 2002 The Features of IPv6 Signaling 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 memo, we describe the features of IPv6 signaling protocol. We also discuss the related issues and the need of new signaling protocol. We will explain the implementation issues in some detail. 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. Choi at el [Page 1] Internet Draft The Features of IPv6 Signaling February 2002 Table of Contents 1. Introduction.....................................................3 2. The Needs of QoS Signaling in IPv6 networks.....................4 2.1. IP related Signaling...........................................4 2.2. The Features of QoS related Signaling in IPv6 Networks........4 2.4 The Needs of QoS Signaling in IPv6 Networks....................6 3. IPv6 Assists the Existing Signaling Protocols...................8 3.1. Using Router Alert Option......................................8 3.2. Using Internet Signaling Message Protocol (ISMP)..............9 3.3. The Use of Assisting Methods in Existing Signaling Protocols.10 4. Signaling Protocols Use the Features of IPv6...................11 4.1. Implementation of the Notification ...........................11 4.2. The Modification in Existing Signaling Protocols.............12 5. Other Issues....................................................13 6. IANA Considerations.............................................13 7. Security Considerations.........................................13 References.........................................................14 Choi at el [Page 2] Internet Draft The Features of IPv6 Signaling February 2002 1. Introduction Many signaling mechanisms are defined and developed to support QoS in IP networks. Those are chosen by users to satisfy their needs, objectives, and implementation costs. Also most of the signaling protocols are based on the underlying network structure, 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). In this paper, we want to make some mechanisms to support signaling protocol that is running in IPv6 network by utilizing the IPv6's native features like Hop-by-Hop Option header, Routing Option header, and Destination Option header as described in [RFC 2460]. 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. Actually, IPv6 has many features to support QoS and other capabilities for the emerged networks. We will describe about that in section 2. Also, those features can be used to help existing signaling mechanisms or used to substitute some functions of existing signaling protocols so to make the signaling protocols more fully using the power of IPv6 features. This work may not be preferred to those who won't like the modification of the existing signaling protocols. Then they can use the features of IPv6 to assist the existing signaling protocols without modifying themselves. On the other hand, one who wants to make use of the features of IPv6 signaling protocols may modify slightly the existing signaling mechanisms to adopt that to the IPv6 networks. Choi at el [Page 3] Internet Draft The Features of IPv6 Signaling February 2002 2. The Needs of QoS Signaling Protocols in IPv6 networks 2.1. IP related Signaling Protocols There are already many signaling protocols in IP networks to provide some control delivering mechanism with or without QoS support. We can classify the signaling mechanisms regarding the actual nodes that are affected by that signaling protocol. A signaling protocol may concern with a pair of node that may be host or router. Like ICMP, that kind of signaling protocol is just for the information notification. On the other hand, like SIP described in [RFC 2543], some signaling may be transferring the QoS related information that can be used to a node to determine the control of resource of the node. There are other kinds of signaling protocols that effect on the nodes on a path of source to destination path. With regarding the QoS, currently RSVP [RFC 2205](or RSVP-TE [RSVP-TE 09]) and LDP[RFC 3036] (or CR-LDP [CR-LDP 05]) is defined to provide QoS in intermediate node of the path in the IP networks. We just use the term "IP network" because any kind of sub layer mechanism can be used to support the transport of IP packets. Other signaling protocols are defined between the neighbors those are connected with link. We will not mention about this case because this case is treated with special case of above two cases. We will regard the signaling protocols that use IP or higher layer and related with QoS mechanisms. 2.2. The Features of QoS related Signaling Protocols in IPv6 Networks We will choose some existing signaling protocols to explain our idea. To validate the further discussion, we must describe the features of signaling mechanisms in IPv6 network with supporting QoS. o QoS parameters Information with QoS controlling is important context of signaling packet. With aggregated flow concept, IPv6 signaling mechanisms can provide finer QoS granularity than DiffServ model, and more scalable than IntServ model. o 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 signaling protocol MUST be able to deal with such resource allocation requests. Choi at el [Page 4] Internet Draft The Features of IPv6 Signaling February 2002 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 with the capability of making intelligent decisions on how resource allocation SHOULD be controlled. o Explicit route In IPv6 specification, there is a route extension header to use explicit route. Explicit route is important for traffic engineering in IPv6 networks, so we can use of this option header. In doing so, signaling packet specify the route with route extension header and data packet is just switched according to flow label in each router on the path specified with signaling packet. There is already ROUTE object in RSVP-TE specification [RSVP-TE 09]. In the case of CR-LDP, some TLVs are defined to be used for this purpose. o 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. o Flow Label Information Distribution To make use of flow label field as mentioned in [IPNGLS 00] and identify the flow label between the routers on specific path, label- binding information SHOULD be delivered between the related routers. The related routers are on the path of the flow. Label value is only meaningful between a pair of routers. And the label value is predetermined before forwarding data packet along the path. o Label Stacking In [IPNGLS 00], label stacking concept is addressed. To enable the label stacking, the signaling protocol is defined to notify the stacking information. But we don't consider the concept in this version. Choi at el [Page 5] Internet Draft The Features of IPv6 Signaling February 2002 2.3. QoS related Signaling Protocol Usually the QoS mechanisms are supported in the IP layer or the Transport layer (for example, TCP or UDP). To simplify the discussion, we will just regard the three signaling protocols, RSVP-TE, CR-LDP, SIP. These signaling protocols are covering the classification in section 2.1 and also these signaling mechanisms can be used for the some or all of QoS supporting features described in 2.2. Also we note that these are running on the IP and TCP (UDP) layer. We will explain these signaling protocols as briefly as possible to make our discussion further. o RSVP-TE RSVP-TE, originated by RSVP is used for the IntServ model described in []. Both RSVP 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. But RSVP-TE doesn't support multicasting environment. o CR-LDP CR-LDP, from LDP, is used for the almost same purpose of RSVP-TE. But this signaling protocol use the TCP (and UDP) layer instead of IP layer in RSVP-TE. So this signaling protocol uses the features of TCP protocol. o SIP To provide the multimedia services, like voice or moving pictures, SIP and other protocols are defined to provide the server and client side QoS mechanism. This protocol use ether TCP or UDP. 2.4 The Needs of QoS Signaling Protocol in IPv6 Networks 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. On the other hand, as mentioned in section 2.2, there are some studies about the make use of flow label field to treat it as a "tag" of packets QoS attribute and packet switching information. So there MUST be signaling mechanism to distribute the flow label information between the routers. Choi at el [Page 6] Internet Draft The Features of IPv6 Signaling February 2002 In the actual relationship of signaling protocols and IPv6 specifications, we can use the features of IPv6 like Hop-by-Hop Option header or Destination Option header to assist the signaling. It can improve the efficiency of IPv6 networks and we can enjoy that without modifying the existing signaling protocols. We also use the IPv6 features like Routing Option header to extract the routing information in signaling protocols. This mechanism should be implemented to leave the use of this option to the user. But if someone uses this kind of functions, he or she may have benefit of consistency in the information that may be duplicated in the original implementation. Choi at el [Page 7] Internet Draft The Features of IPv6 Signaling February 2002 3. IPv6 Assists the Existing Signaling Protocols In this section, we will describe the methods of assisting existing signaling protocols in IPv6 networks via using IPv6 extension headers. The use of these methods in existing signaling protocols is discussed in the last of this section. 3.1. Using Router Alert Option Router alert option [RFC 2711] 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. [RFC 2460] 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 [RFC 2710]. 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. Choi at el [Page 8] Internet Draft The Features of IPv6 Signaling February 2002 The described method has some advantages and disadvantages. It is not necessary to implement the new protocol for signaling. The existing 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. 3.2. Using Internet Signaling Message Protocol (ISMP) We propose the new protocol, Internet Signaling Message Protocol (ISMP), such like the ICMPv6 [RFC 2463]. ISMP is used to carry signaling messages. Every ISMP message is preceded by an IPv6 header or by more IPv6 extension headers. The ISMP message is identified by a Next Header value in the immediately preceding header. The ISMP 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. Choi at el [Page 9] Internet Draft The Features of IPv6 Signaling February 2002 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 IPv6 header. Uses the same values as the IPv4 Protocol field [RFC 1700 et seq.]. 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 [RFC 1700]. 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 second method may be used for the signaling protocols which are running on the IP layer. Compared with the method using router alert option, 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. 3.3. The Use of Assisting Methods in Existing Signaling Protocols In the case of RSVP-TE, if the header of a packet is indicating "This packet carries the signaling information." then the intermediate routers and the end host 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 router sees the notification Choi at el [Page 10] Internet Draft The Features of IPv6 Signaling February 2002 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. Lastly, the signaling protocols, like SIP, 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. 4. Signaling Protocols Use the Features of IPv6 We focus on the features of IPv6 protocol related with the Routing Option header. Like RSVP-TE and CR-LDP, QoS signaling may have explicit routing information. But IPv6 also defines the Routing Option header that indicates the route that the packet must be passed. If the same information is located in two points with same packet, the consistency problem may be arisen. Also the duplication of the information is clearly redundancy. So we should define the field that indicates the use of Routing Option header to route of the packet must be passed. And the explicit route information in the payload of the packet can be omitted. Then the packet can make use of IPv6 Routing Option header processing modules on the router and the processing time can be reduced than that of the signaling protocol processor. Of course the little modification is required both the source node and intermediate nodes. On the other hand, someone still use the signaling without modifying that. So we propose the TVL option to determine the use of this method. 4.1. Implementation of the Notification To notify the information that a packet use the IPv6 Routing Header option to specify its route is i) by defining the new version of RSVP-TE and CR-LDP, namely RSVP-TE- IPv6 and CR-LDP-IPv6 and assign new protocol number used for signaling protocol indication information described in section 3. ii) by defining additional TLV to indicate that the signaling protocol use the Routing Option header to specify the explicit route information. We propose a TLV in Hop-by-Hop option header to do this. Choi at el [Page 11] Internet Draft The Features of IPv6 Signaling February 2002 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 0|0 0 1 1 0|0 0 0 0 0 0 1 0| Value (2 octets) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ length = 2 The first three bits of the first byte are zero that the meaning of this value is described in section 3.1. There MUST only be one option of this type, regardless of value, per Hop-by-Hop header. So we do not consider the case that a packet carries more than one signaling protocol, i.e. RSVP-TE and CR-LDP. Value: A 2 octets code in network byte order with the following values 0 The signaling information in this packet does not depend on the Routing Option header may exist in this header. 1 The signaling information in this packet makes use of Routing Option header to specify the explicit route of this packet. Alignment requirement: 2n+0 4.2. The Modification in Existing Signaling Protocols The routers running on IPv6 networks MUST follow the specification of IPv6 protocol. So they examine the Hop-by-Hop Option header and determine the treatment of the packet related with the Routing Option header. If a packet want to use the Routing Option header to specify it's explicit route : o In the case of RSVP-TE For the PATH message, the routers on the path SHOULD use the route information in Routing Option header of the signaling packet and maintain the flow state information with the hop information of the message was sent. It is used for the RESV message to be sent reverse direction that the PATH message was sent. The actual forwarding of PATH message is done in IPv6 router automatically. o In the case of CR-LDP If a node send Label Request message, the routers on the path don't need to record the node that send the message. Instead of that, the end node SHOULD reverse information of the message was transferred, i.e. the addresses of Routing Option header. Then the end node makes the Routing Option header exactly reverse of the route before send the Label Reply message. Choi at el [Page 12] Internet Draft The Features of IPv6 Signaling February 2002 5. Other Issues The problems arise from the tunneling such like mobile IPv6 mechanisms are not fully exploited in this version of document. Also the more detail procedure of signaling packet processing in CR-LDP and RSVP-TE in case of the explicit route information is carried in Routing Option header should be considered. We are studying about these issues. 6. 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]. 7. Security Considerations This document does not have any security concerns. The security requirements using this document are described in the referenced documents. Choi at el [Page 13] Internet Draft The Features of IPv6 Signaling February 2002 References [RFC 1700] J. Reynolds et al.. "Assign Numbers", October 1994 [RFC 2205] R. Braden, Ed. et al.. "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", September 1997 [RFC 2434] T. Narten, et al.. "Guidelines for Writing an IANA Considerations Section in RFCs", October 1998 [RFC 2460] S. Deering, et al.. "Internet Protocol, Version 6 (IPv6) Specification", December 1998 [RFC 2463] A. Conta, et al.. "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification", December 1998 [RFC 2475] S. Blake, et al.. "An Architecture for Differentiated Services", December 1998 [RFC 2543] M. Handley, et al.. "SIP: Session Initiation Protocol", March, 1999 [RFC 2710] S. Deering, et al.. "Multicast Listener Discovery (MLD) for IPv6", October 1999 [RFC 2711] C. Partridge, et al.. "IPv6 Router Alert Option", October 1999 [RFC 3031] E. Rosen, et al.. "Multiprotocol Label Switching Architecture", January 2001 [RFC 3036] L. Andersson, et al.. "LDP Specification", January 2001 [RSVP-TE 09] Daniel O. Awduche et al.. "RSVP-TE: Extensions to RSVP for LSP Tunnels-09", Internet Draft, August 2001 [CR-LDP 05] Jamoussi, et al.. "Constraint-Based LSP Setup using LDP", Internet Draft, February 2001 [IPNGLS 00] V. Roesler et al.. "IPNGLS - IP Next Generation Label Switching-00", Internet Draft, September, 2001 [RSVP-MIPv6 00] Charles Qi Shen, et al.. "An Interoperation Framework for Using RSVP in Mobile IPv6 Networks-00", Internet Draft, July 2001 Choi at el [Page 14] Internet Draft The Features of IPv6 Signaling February 2002 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 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 Ki Young Jung Information and Communications University (ICU) 58-4 Hwa Ahm Dong, Yusong, Taejon Korea 305-732 Phone: +82-42-866-6182 Email: jjungki@icu.ac.kr Document: draft-choi-ipv6-signaling-01.txt Expiration Date: August 2002 Choi at el [Page 15]