idnits 2.17.1 draft-choi-ipv6-signaling-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: 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. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (June 2002) is 7986 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC 2463' is defined on line 594, but no explicit reference was found in the text == Unused Reference: 'RFC 2475' is defined on line 598, but no explicit reference was found in the text == Unused Reference: 'RFC 3031' is defined on line 610, but no explicit reference was found in the text ** Obsolete normative reference: RFC 1700 (Obsoleted by RFC 3232) ** Obsolete normative reference: RFC 2434 (Obsoleted by RFC 5226) ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) ** Obsolete normative reference: RFC 2463 (Obsoleted by RFC 4443) ** Downref: Normative reference to an Informational RFC: RFC 2475 ** Obsolete normative reference: RFC 2543 (Obsoleted by RFC 3261, RFC 3262, RFC 3263, RFC 3264, RFC 3265) ** Obsolete normative reference: RFC 3036 (Obsoleted by RFC 5036) == Outdated reference: A later version (-07) exists of draft-ietf-mpls-generalized-cr-ldp-06 == Outdated reference: A later version (-09) exists of draft-ietf-mpls-generalized-rsvp-te-07 Summary: 10 errors (**), 0 flaws (~~), 7 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Draft Jun Kyun Choi 2 Document: draft-choi-ipv6-signaling-02.txt Gyu Myoung Lee 3 Expiration Date: December 2002 Ki Young Jung 4 ICU 5 Woo Seop Rhee 6 ETRI 7 June 2002 9 The Features of IPv6 Signaling 11 Status of this Memo 13 This document is an Internet-Draft and is in full conformance with 14 all provisions of Section 10 of RFC-2026. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that other 18 groups may also distribute working documents as Internet-Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsolete by other documents at any 22 time. It is inappropriate to use Internet- Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 Abstract 33 In this draft, we describe the features and requirements of IPv6 34 signaling protocol and explain the needs of QoS signaling in IPv6 35 network. We also explain mapping of IPv6 signaling with IPv4 in some 36 detail. 38 Conventions 40 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 41 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 42 document are to be interpreted as described in RFC-2119. 44 Choi et al Expires - December 2002 [Page 1] 45 Table of Contents 47 1. Introduction.....................................................2 48 2. The Needs of QoS Signaling in IPv6 networks......................3 49 2.1. IP related Signaling Protocols..............................3 50 2.2. QoS related Signaling Protocols.............................3 51 2.3. The Features of QoS related Signaling in IPv6 Networks......4 52 2.4. The Requirements of QoS Signaling Protocol in IPv6 Networks.5 53 3. Mapping of IPv6 Signaling with IPv4..............................7 54 4. Other Issues.....................................................9 55 5. IANA Considerations..............................................9 56 6. Security Considerations..........................................9 57 Appendix. The delivering methods of signaling messages in IPv6 58 network............................................................10 59 References.........................................................14 60 Acknowledgements...................................................15 61 Author's Addresses.................................................15 63 1. Introduction 65 Many signaling mechanisms are defined and developed to support 66 Quality of Service (QoS) in IP networks. Those are chosen by users to 67 satisfy their needs, objectives, and implementation costs. Also most 68 of the signaling protocols are based on the underlying network 69 infrastructure, i.e. IP networks, but they don't depend on the minor 70 version of the network. For example, one signaling protocol designed 71 for the IPv4 network can be used in IPv6 network without modifying 72 the specification of the signaling mechanism. Rather than to do like 73 that, the signaling protocol adopt itself to the different version of 74 network implementation by defining option fields like IP version 75 information field and related information like IPv4 addresses (32 76 bits) or IPv6 addresses (128 bits). 78 Actually, IPv6 has many features to support QoS and other 79 capabilities for the emerged networks. We will describe about that in 80 section 2. Also, those features can be used to help existing IPv4 81 based signaling mechanisms or used to substitute some functions of 82 existing signaling protocols in order to make the signaling protocols 83 more fully using the power of IPv6 features. 85 In this draft, we describe the features and requirements of IPv6 86 signaling protocol to explain the needs of QoS signaling in IPv6 87 network. Deployment point of view, we also explain three stages of 88 evolution scenarios and mapping of IPv6 signaling with IPv4 in some 89 detail. Finally, the delivering methods of signaling messages in IPv6 90 network are presented in appendix. 92 Choi et al Expires - December 2002 [Page 2] 93 2. The Needs of QoS Signaling in IPv6 networks 95 2.1. IP related Signaling Protocols 97 There are already many signaling protocols in IP networks to provide 98 some control delivering mechanism with or without QoS support. We can 99 classify the signaling mechanisms regarding the actual nodes that are 100 affected by that signaling protocol. 102 A signaling protocol may concern with a pair of node that may be host 103 or router. Like ICMP, that kind of signaling protocol is just for the 104 information notification. On the other hand, like SIP described in 105 [RFC 2543], some signaling may be transferring the QoS related 106 information that can be used to a node to determine the control of 107 resource of the node. 109 There are other kinds of signaling protocols that effect on the nodes 110 on a path of source to destination path. With regarding the QoS, 111 currently RSVP [RFC 2205](or RSVP-TE [RFC 3209]) and LDP[RFC 3036] 112 (or CR-LDP [RFC 3212]) is defined to provide QoS in intermediate node 113 of the path in the IP networks. We just use the term "IP network" 114 because any kind of sub layer mechanism can be used to support the 115 transport of IP packets. 117 Other signaling protocols are defined between the neighbors those are 118 connected with link. We will not mention about this case because this 119 case is treated with special case of above two cases. 120 We will regard the signaling protocols that use IP or higher layer 121 and related with QoS mechanisms. 123 2.2. QoS related Signaling Protocols 125 Usually the QoS mechanisms are supported in the IP layer or the 126 Transport layer (for example, TCP or UDP). To simplify the discussion, 127 we will just regard the three signaling protocols, RSVP-TE, CR-LDP, 128 SIP. These signaling protocols are covering the classification in 129 section 2.1 and also these signaling mechanisms can be used for the 130 some or all of QoS supporting features described in 2.3. Also we note 131 that these are running on the IP and TCP (UDP) layer. We will explain 132 these signaling protocols as briefly as possible to make our 133 discussion further. 135 o RSVP-TE (including RSVP-TE extension for GMPLS [RSVP-TE 07]) 137 RSVP-TE, originated by RSVP is used for the IntServ model described 138 in [RFC 2210]. Both RSVP and RSVP-TE are implemented on the IP layer. 139 RSVP is defined to support QoS in IP network with fine granularity, 140 but this leads the scalability problems. RSVP-TE has some additional 141 concepts, like label distribution, aggregated flow, and explicit 142 route. But RSVP-TE doesn't support multicasting environment. 144 Choi et al Expires - December 2002 [Page 3] 145 o CR-LDP (including CR-LDP extension for GMPLS [CR-LDP 06]) 147 CR-LDP, from LDP, is used for the almost same purpose of RSVP-TE. But 148 this signaling protocol use the TCP (and UDP) layer instead of IP 149 layer in RSVP-TE. So this signaling protocol uses the features of TCP 150 protocol. 152 o SIP and H.323 154 To provide the multimedia services, like voice or moving pictures, 155 SIP and other protocols are defined to provide the server and client 156 side QoS mechanism. This protocol use ether TCP or UDP. 158 2.3. The Features of QoS related Signaling in IPv6 Networks 160 We will choose some existing signaling protocols to explain our idea. 161 To validate the further discussion, we must describe the features of 162 signaling mechanisms in IPv6 network with supporting QoS. 164 o QoS support 166 Information with QoS controlling is important context of signaling 167 packet. With aggregated flow concept, IPv6 signaling mechanisms can 168 provide finer QoS granularity than DiffServ model, and more scalable 169 than IntServ model. 171 o Resource Reservation 173 The key role of signaling protocol is to allocate and reserve the 174 network resource for the purpose of meeting end-to-end QoS 175 requirements along the entire path. The signaling protocol MUST be 176 able to deal with such resource allocation requests. 178 o Priority Flow Control 180 Each node has many flows with different priority of various data 181 rates and QoS requirements. These flows are classified and scheduled 182 with the capability of making intelligent decisions on how resource 183 allocation SHOULD be controlled. 185 o Explicit route 187 In IPv6 specification, there is a route extension header to use 188 explicit route. Explicit route is important for traffic engineering 189 in IPv6 networks, so we can use of this option header. In doing so, 190 signaling packet specify the route with route extension header and 191 data packet is just switched according to flow label in each router 192 on the path specified with signaling packet. There is already ROUTE 193 object in RSVP-TE specification [RFC 3209]. In the case of CR-LDP, 194 some TLVs are defined to be used for this purpose. 196 Choi et al Expires - December 2002 [Page 4] 197 o Scalability 199 The performance of the signaling protocol SHOULD not largely depend 200 on the scale of the network to which IPv6 is applied (e.g. the number 201 of nodes, the number of physical links etc). The signaling function 202 SHOULD keep constant performance as much as possible regardless of 203 network size. Aggregating flows can reduce resource allocation and 204 runtime management overhead. 206 o Flow Label Information Distribution 208 To make use of flow label field [Flow Label 02] of IPv6 basic header 209 and identify the flow label between the routers on specific path, 210 label-binding information SHOULD be delivered between the related 211 routers. The related routers are on the path of the flow. Label value 212 is only meaningful between a pair of routers. And the label value is 213 predetermined before forwarding data packet along the path. 215 o Label Stacking 217 In Label Switching, label stacking concept is addressed. To enable 218 the label stacking, the signaling protocol is defined to notify the 219 stacking information. But we don't consider the concept in this 220 version. 222 2.4. The Requirements of QoS Signaling Protocol in IPv6 Networks 224 Besides of features of signaling, we SHOUD consider the following 225 requirements of QoS signaling in IPv6 networks. 227 o Make use of IPv6 features 229 IPv6 have many features to make use of that to provide some new 230 functions. For example, one can want to use the IPv6 Routing Option 231 header to send signaling packet along the desired path rather than 232 the shortest path. This is reasonable because the IPv6 routers may be 233 implement routing option header processing component so we can use 234 that without any additional functional implementations. Also we can 235 think about the hop-by-hop header to notify routers that the packets 236 have some signaling and reservation information. These things are 237 already considered in other signaling mechanism. That means we can 238 use the IPv6 native features or don't use of them. There is another 239 viewpoint related with this. If the same information is transferred 240 with IPv6 header and payload, there may exist the consistency 241 problems. So some people want to make one of choices, not both of 242 them. 244 Choi et al Expires - December 2002 [Page 5] 245 o Backward compatibility 247 The existing signaling protocols such as RSVP, RSVP-TE, CR-LDP and so 248 on are implemented in IPv4 network. These signaling protocols MUST be 249 operated in IPv6 network. Therefore, they MUST support backward 250 compatibility for operating both IPv6 and IPv4. 252 o Easy to implement 254 There are two aspects related with this issue. First, we can consider 255 the compatibility of the new signaling with existing signaling. So 256 the implementation can be done with minimum modification of previous 257 architecture and components. Second we can omit some functions of 258 previous signaling so that we just make a light-weight signaling 259 mechanism. We are still studying about this carefully because it 260 makes some effects with other various factors such like the 261 capabilities of this new signaling and the signaling translation 262 between two heterogeneous AS's. We can think above two factors 263 simultaneously and SHOULD make some trade-off. 265 o Signaling interworking between IPv6 and IPv4 267 To be gradually deployed, we can consider the situation of mixed 268 nodes that some implement the IPv6 signaling and others implement 269 the IPv4 signaling. In this environment, we consider signaling 270 interworking issues. So we will explain mapping of IPv6 signaling 271 with IPv4 in section 3. 273 o Traffic parameters for QoS negotiation 275 There are many traffic parameters such as peak data rate, peak burst 276 size, committed data rate, committed burst size, excess burst size 277 and so on. The QoS signaling applies the traffic parameters per 278 aggregated flow. To make use of this, state of QoS information SHOLD 279 be maintained per aggregated flow. Also the adding and deleting of a 280 flow with respect to the aggregated flow SHOULD be carefully managed. 281 An aggregated flow is not just used for label-related switching, but 282 also used for classification information in routers on path. So the 283 traffic parameter information SHOULD be stored in the router with the 284 information related with an aggregated flow identifier(s). 286 o Mobility support 288 To provide the QoS in mobile environment, we SHOLD consider the 289 mobility of nodes and dynamic behavior of related flows. In signaling, 290 we are concerning two problems. First the flow management can be 291 considered with per aggregated flow or per flow. In some point, 292 snapshot of network can be described with many aggregated flows and 293 related QoS management. But as time goes, some flow of mobile node 295 Choi et al Expires - December 2002 [Page 6] 296 departs one aggregated flow and join the other aggregated flow. 297 Second the support of micro mobility issues. To make use of old flow 298 related resources as much as possible, we should define Nearest 299 Common Router (NCR) and provide the finding mechanism. This work is 300 under working. We just consider the need of modification or 301 adaptation of that mechanism in our work. 303 o Inter-operation with other QoS-supporting networks 305 In this version, we cannot consider this issue. 307 3. Mapping of IPv6 Signaling with IPv4 309 The current Internet will smoothly transit from IPv4 to IPv6. 310 Deployment point of view, we consider three stages of evolution 311 scenarios 313 - first stage (stage 1): IPv4 ocean and IPv6 island 314 - second stage (stage 2): IPv6 ocean and IPv4 island 315 - third stage (stage 3): IPv6 ocean and IPv6 island 317 In first stage shown in Figure 1, MPLS-based core network (e.g., IPv4 318 ocean) and IPv6 access network (e.g., IPv6 island)is deployed. In 319 this environment, core signaling such as RSVP-TE and CR-LDP is used 320 in IPv4 ocean and access signaling such as RSVP and RSVP-TE is used 321 in IPv6 island. To support end-to-end QoS signaling, these protocols 322 SHOUD perform the mapping of IPv6 signaling with IPv4. Flow label 323 information of IPv6 header is translated to FEC(Forwarding Equivalent 324 Class) information of MPLS. For this reason, signaling interworking 325 function is needed. Using this QoS signaling, flow information is 326 transmitted unchanged from source to destination and the required 327 resource is reserved and end to end path is established. 329 +-------------+ +---------------+ +-------------+ 330 | IPv6 island |-------| IPv4 ocean |-------| IPv6 island | 331 | |-------| (MPLS) |-------| | 332 +-------------+ +---------------+ +-------------+ 333 Flow Label -- mapping -- FEC -- mapping -- Flow Label 335 |<----------->| |<------------->| |<----------->| 336 RSVP/RSVP-TE RSVP-TE/CR-LDP RSVP/RSVP-TE 337 (Access signaling) (Core signaling) (Access signaling) 339 |<--------------------------------------------------------->| 340 end-to-end QoS signaling 342 Figure 1. Signaling mapping (stage 1) 344 Choi et al Expires - December 2002 [Page 7] 345 In second stage shown in Figure 2, IPv6 network will dominate over 346 IP4 network. This network is composed of IPv6-based core network 347 (e.g., IPv6 ocean) and IPv4-based access network (e.g., IPv4 island). 348 The existing IPv4 network is operated in MPLS. In this environment, 349 core signaling such as RSVP-TE and CR-LDP is used in IPv6 ocean and 350 access signaling such as RSVP and RSVP-TE is used in IPv4 island. FEC 351 information of IPv4 is translated to flow label information of IPv6. 353 +-------------+ +---------------+ +-------------+ 354 | IPv4 island |-------| IPv6 ocean |-------| IPv4 island | 355 | (MPLS) |-------| |-------| (MPLS) | 356 +-------------+ +---------------+ +-------------+ 357 FEC -- mapping -- Flow Label -- mapping -- FEC 359 |<----------->| |<------------->| |<----------->| 360 RSVP/RSVP-TE RSVP-TE/CR-LDP RSVP/RSVP-TE 361 (Access signaling) (Core signaling) (Access signaling) 363 |<--------------------------------------------------------->| 364 end-to-end QoS signaling 366 Figure 2. Signaling mapping (stage 2) 368 In third stage shown in Figure 3, IPv6 protocol is implemented both 369 core network (e.g., IPv6 ocean) and access network (e.g., IPv6 370 island). Signaling protocol like RSVP-TE MAY be used without 371 signaling translation. 373 +-------------+ +---------------+ +-------------+ 374 | IPv6 island |-------| IPv6 ocean |-------| IPv6 island | 375 +-------------+ +---------------+ +-------------+ 376 Flow Label -- mapping -- Flow Label -- mapping - Flow Label 378 |<----------->| |<------------->| |<----------->| 379 RSVP/RSVP-TE RSVP-TE/CR-LDP RSVP/RSVP-TE 380 (Access signaling) (Core signaling) (Access signaling) 382 |<--------------------------------------------------------->| 383 end-to-end QoS signaling 385 Figure 3. Signaling mapping (stage 3) 387 Choi et al Expires - December 2002 [Page 8] 388 4. Other Issues 390 The problems arise from the tunneling such like mobile IPv6 391 mechanisms are not fully exploited in this version of document. Also 392 the more detail procedure of signaling packet processing in CR-LDP 393 and RSVP-TE in case of the explicit route information is carried in 394 Routing Option header should be considered. We are studying about 395 these issues. 397 5. IANA Considerations 399 The value field described in appendix SHOULD be registered and 400 maintained by IANA. The New values SHOULD be to be assigned via IETF 401 Consensus as defined in [RFC 2434]. 403 6. Security Considerations 405 This document does not have any security concerns. The security 406 requirements using this document are described in the referenced 407 documents. 409 Choi et al Expires - December 2002 [Page 9] 410 Appendix. The delivering methods of signaling messages in IPv6 network 412 In this appendix, we will describe the delivering methods of existing 413 signaling protocols in IPv6 networks via using IPv6 extension headers. 414 The use of these methods in existing signaling protocols is discussed 415 in the last of this section. 417 1. RSVP/RSVP-TE for IPv6 (including RSVP-TE extension for GMPLS) 419 o Using Router Alert Option 421 Router alert option [RFC 2711] within the IPv6 Hop-by-Hop option 422 header has the semantic "routers should examine the datagram more 423 closely". Using this option, IPv6 datagram containing signaling 424 messages are indicated and taken actions. 426 The router alert option has the following format: 428 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 429 |0 0 0|0 0 1 0 1|0 0 0 0 0 0 1 0| Value (2 octets) | 430 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 431 length = 2 433 The first three bits of the first byte are zero and the value 5 in 434 the remaining five bits is the Hop-by-Hop Option Type number. 435 [RFC 2460] specifies the meaning of the first three bits. By 436 zeroing all three, this specification requires that nodes not 437 recognizing this option type should skip over this option and 438 continues processing the header and that the option must not change 439 en route. 441 There MUST only be one option of this type, regardless of value, 442 per Hop-by-Hop header. 444 Value: A 2 octets code in network byte order with the following 445 values 447 0 Datagram contains a Multicast Listener Discovery 448 message [RFC 2710]. 449 1 Datagram contains RSVP message. 450 2 Datagram contains an Active Networks message. 451 3-65535 Reserved to IANA for future use. 453 Alignment requirement: 2n+0 455 Values are registered and maintained by the IANA. 457 We suggest the new value (= 3) for RSVP-TE messages. The value 3 is 458 REQUIRED the approval of IETF and SHOULD be assigned by IANA. Other 460 Choi et al Expires - December 2002 [Page 10] 461 signaling messages MAY be added. In this case, the value for new 462 signaling message SHOULD be assigned by IANA. 464 The described method has some advantages and disadvantages. It is not 465 necessary to implement the new protocol for signaling. The existing 466 signaling message is used without change. However, all IPv6 datagram 467 containing a signaling message MUST contain this option within the 468 IPv6 Hop-by-Hop Option Header of such datagram. The additional option 469 header is redundant. 471 o Next Header for signaling 473 This method uses the new Next Header value for signaling message. 474 Message body includes signaling messages like RSVP/RSVP-TE. Every 475 signaling message is preceded by an IPv6 header or by more IPv6 476 extension headers. The signaling message is identified by a Next 477 Header value in the immediately preceding header. 479 The signaling messages have the following general format: 481 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 482 |Version| Traffic Class | Flow Label | 483 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 484 | Payload Length | Next Header | Hop Limit | 485 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 486 | | 487 + + 488 | | 489 + Source Address + 490 | | 491 + + 492 | | 493 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 494 | | 495 + + 496 | | 497 + Destination Address + 498 | | 499 + + 500 | | 501 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 502 + + 503 | Message Body | 504 + (signaling message) + 506 Version 4-bit Internet Protocol version number = 6. 508 Traffic Class 8-bit traffic class field. 510 Choi et al Expires - December 2002 [Page 11] 511 Flow Label 20-bit flow label. 513 Payload Length 16-bit unsigned integer. Length of the IPv6 514 payload, i.e., the rest of the packet 515 following this IPv6 header, in octets 517 Next Header 8-bit selector. Identifies the type of 518 signaling message immediately following the 519 IPv6 header. Uses the same values as the 520 IPv4 Protocol field [RFC 1700 et seq.]. 522 Hop Limit 8-bit unsigned integer. Decremented by 1 by 523 each node that forwards the packet. The 524 packet is discarded if Hop Limit is 525 decremented to zero. 527 Source Address 128-bit address of the originator of the 528 packet. 530 Destination Address 128-bit address of the intended recipient of 531 the packet (possibly not the ultimate 532 recipient, if a Routing header is present). 534 For this method, we MUST assign the new Next Header value of IPv6 535 header. Currently, RSVP is already assigned the value 46 decimal in 536 [RFC 1700]. 538 For example, if the Next Header value of IPv6 header is 46 decimal 539 the following ISMP message is RSVP message. The Next Header value of 540 other unassigned signaling messages SHOULD be assigned by IANA. 542 This second method may be used for the signaling protocols which are 543 running on the IP layer. 545 Compared with the method using router alert option, this method is 546 very simple because of no additional extension header. Therefore, the 547 complexity of processing is reduced but this new function MUST be 548 implemented within IPv6 header. 550 Note) The signaling protocols, like SIP, that are used for end-to- 551 end path may use the option TLVs to indicate the presence of the 552 signaling information. We already know that the real-time service 553 cannot be served without support of intermediate node. If some 554 end-to-end sessions are need to be guaranteed to their perceived 555 QoS, the intermediate nodes those are on the path may use the 556 information to do something related with QoS implicitly. 558 Choi et al Expires - December 2002 [Page 12] 559 2. CR-LDP for IPv6 (including CR-LDP extension for GMPLS) 561 In the case of RSVP-TE, if the header of a packet is indicating "This 562 packet carries the signaling information." then the intermediate 563 routers and the end host can make different treatment on just only 564 look at the IP header. 566 On the other hand, like CR-LDP, the protocol running on the TCP(UDP) 567 layer may also make use of the benefit that IP header already notify 568 the existence of signaling information in the payload of IP packet. 569 Originally in the CR-LDP protocol, the signaling information is 570 transferred along the path per hop. If a router sees the notification 571 of signaling information in the IP header, it can forward the 572 signaling packet and processing the signaling information 573 simultaneously. So the forwarding direction of packet can be done 574 faster than old mechanisms. 576 Choi et al Expires - December 2002 [Page 13] 577 References 579 [RFC 1700] J. Reynolds et al.. "Assign Numbers", October 1994 581 [RFC 2205] R. Braden, Ed. et al.. "Resource ReSerVation Protocol 582 (RSVP) -- Version 1 Functional Specification", September 583 1997 585 [RFC 2210] J. Wroclawski et al.. "The use of RSVP with IETF 586 Integrated Services", September 1997 588 [RFC 2434] T. Narten, et al.. "Guidelines for Writing an IANA 589 Considerations Section in RFCs", October 1998 591 [RFC 2460] S. Deering, et al.. "Internet Protocol, Version 6 (IPv6) 592 Specification", December 1998 594 [RFC 2463] A. Conta, et al.. "Internet Control Message Protocol 595 (ICMPv6) for the Internet Protocol Version 6 (IPv6) 596 Specification", December 1998 598 [RFC 2475] S. Blake, et al.. "An Architecture for Differentiated 599 Services", December 1998 601 [RFC 2543] M. Handley, et al.. "SIP: Session Initiation Protocol", 602 March, 1999 604 [RFC 2710] S. Deering, et al.. "Multicast Listener Discovery (MLD) 605 for IPv6", October 1999 607 [RFC 2711] C. Partridge, et al.. "IPv6 Router Alert Option", October 608 1999 610 [RFC 3031] E. Rosen, et al.. "Multiprotocol Label Switching 611 Architecture", January 2001 613 [RFC 3036] L. Andersson, et al.. "LDP Specification", January 2001 615 [RFC 3209] D. Awduche et al.. "RSVP-TE: Extensions to RSVP for LSP 616 Tunnels", December 2001 618 [RFC 3212] B. Jamoussi, et al.. "Constraint-Based LSP Setup using 619 LDP", January 2002 621 [CR-LDP 06] Peter Ashwood-Smith, et al.. "Generalized MPLS Signaling 622 - CR-LDP Extensions", Internet-Draft draft-ietf-mpls- 623 generalized-cr-ldp-06.txt, work in progress, April 2002 625 [RSVP-TE 07] Lou Berger, et al.. "Generalized MPLS Signaling - RSVP- 626 TE Extensions", Internet-Draft draft-ietf-mpls- 627 generalized-rsvp-te-07.txt, work in progress, April 2002 629 Choi et al Expires - December 2002 [Page 14] 631 [Flow Label 02] J. Rajahalme, et al.. "IPv6 Flow Label Specification", 632 Internet-Draft draft-ietf-ipv6-flow-label-02.txt, work in 633 progress, June 2002 635 Acknowledgements 637 This work was supported in part by KOSEF(Korea Science and 638 Engineering Foundation) and MIC(Ministry of Information and 639 Communication) of Korean government. 641 Author's Addresses 643 Jun Kyun Choi 644 Information and Communications University (ICU) 645 58-4 Hwa Ahm Dong, Yuseong, Daejeon 646 Korea 305-732 647 Phone: +82-42-866-6122 648 Email: jkchoi@icu.ac.kr 650 Gyu Myoung Lee 651 Information and Communications University (ICU) 652 58-4 Hwa Ahm Dong, Yuseong, Daejeon 653 Korea 305-732 654 Phone: +82-42-866-6231 655 Email: gmlee@icu.ac.kr 657 Ki Young Jung 658 Information and Communications University (ICU) 659 58-4 Hwa Ahm Dong, Yuseong, Daejeon 660 Korea 305-732 661 Phone: +82-42-866-6182 662 Email: jjungki@icu.ac.kr 664 Woo Seop Rhee 665 Electronics and Telecommunications Research Institute (ETRI) 666 161 Kajeong, Youseong, Daejeon 667 Korea 305-350 668 Phone: +82-42-860-5324 669 Email: wsrhee@etri.re.kr 671 Document: draft-choi-ipv6-signaling-02.txt 673 Expiration Date: December 2002