idnits 2.17.1 draft-fujikawa-ric-srsvp-01.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: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document is more than 15 pages and seems to lack a Table of Contents. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 23 longer pages, the longest (page 2) being 60 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 41 instances of too long lines in the document, the longest one being 2 characters in excess of 72. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 203: '... A Path message MUST include a sessio...' RFC 2119 keyword, line 204: '... MAY include FAQ, PQ and policy if n...' RFC 2119 keyword, line 213: '... Resv1. Resv0 MUST include session a...' RFC 2119 keyword, line 214: '...(s) and Sspec, and MAY include FAQ and...' RFC 2119 keyword, line 224: '...n error code. A PathTear/ResvTear MUST...' (1 more instance...) Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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 (25 March 2001) is 8432 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) -- Possible downref: Normative reference to a draft: ref. 'SS' -- Possible downref: Normative reference to a draft: ref. 'HQLIP' Summary: 8 errors (**), 0 flaws (~~), 2 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET DRAFT FUJIKAWA Kenji 3 draft-fujikawa-ric-srsvp-01.txt SHENG Wei 4 Kyoto University 6 Real Internet Consortium 7 25 March 2001 9 Simple Resource ReSerVation Protocol (SRSVP) 11 Status of this Memo 13 This document is an Internet-Draft and is in full conformance 14 with all provisions of Section 10 of RFC2026. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as 19 Internet-Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six 22 months and may be updated, replaced, or obsoleted by other 23 documents at any time. It is inappropriate to use Internet- 24 Drafts as reference material or to cite them other than as 25 "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 Abstract 35 This draft describes Simple Resource ReSerVation Protocol (SRSVP), 36 which implements multicasting, resource reservation and charging in 37 the Internet. 39 1. Introduction 41 Simple Resource ReSerVation Protocol (SRSVP) is an extension of 42 Resource ReSerVation Protocol (RSVP) [RSVP], and the purposes of it is 43 as follows: 44 * Multicasting 45 * Resource reservation 46 * Charging 48 SRSVP creates multicast flows and resource-reserved flows (QoS flows). 49 The state of a QoS flow is hard-state. 51 SRSVP implements both of unicast and multicast resource reservations 52 by a method of receiver-initiated resource reservation. 54 1.1 Specification of QoS 56 Quality of Services (QoSes) specified by hosts are defined in [SS]. 58 1.2 Terminology 60 Flow 61 A flow is a unit of resource reservation. There are two type of 62 flows, a uni-source flow and a multi-source flow. 64 Uni-source flow 65 A flow is identified by protocol number, source address, source 66 port, destination address, and destination port. Currently, a 67 flow is regarded as a uni-source flow when the destination 68 address of its session is unicast. 70 Multi-source flow 71 A flow is identified by protocol number, destination address, 72 and destination port. Currently, a flow is regarded as a 73 multi-source one when the destination address of its session is 74 multicast. 76 Rendezvous Point (RVP) 77 A sender which forwards data in the case of a multi-source 78 flow. It is generally an application gateway, and does not have 79 to be a router. 81 State of a flow 82 State of a flow that a router manages. This includes incoming 83 interfaces of Resv/Path and outgoing interfaces of Resv/Path. 85 Routing Entry 86 The information for forwarding a packet which incomes from a 87 certain interface to a defined interface. An entry of a routing 88 table. 90 Area Information 91 A router advertises information of addresses and charging as 92 area information. Area information is global. See [HQLIP] for 93 details. 95 Link Information 96 A link links an area to another area. A router advertises a 97 metric and QoS parameters of bandwidth and delay as link 98 information. Link information is global. There are two types of 99 link information, external link information and internal link 100 information. See [HQLIP] for details. 102 Service Spec (Sspec) 103 Specification of traffic that sender and receiver specify. A 104 resource reservation is not established when two Sspec's of 105 them match. 107 Path QoS (PQ) 108 A PQ shows link information at a link from the viewpoint of a 109 reservation when the reservation is established. Assuming that 110 a link of 10Kpps/50msec exists, a reservation is 3Kpps/50msec, 111 and the link advertises 8Kpps/100msec as a result. In this 112 case, the PQ shows 10Kpps/50msec is available. A PQ is local 113 for each reservation. 115 First Aggregated QoS (FAQ) 116 Receivers and en-route routers may not get information around a 117 sender or an RVP. A FAQ is a set of calculated QoSes from a 118 sender or an RVP to centers of the areas containing it, and is 119 sent to the receivers and en-route routers. A FAQ is local for 120 each reservation. 122 Policy 123 A policy defined in SRSVP is for charging, and specifies for 124 which areas a sender should pay according to a certain 125 reservation. 127 2. Multicast Model 129 The multicast model of SRSVP is based on RVP like PIM-SM. However, an 130 RVP is generally an application gateway, and does not have to be a 131 router. Distinguishable reservations (flows) are established, between 132 a sender and an RVP, and between an RVP and receivers. A sender can be 133 an RVP. Each sender sends multicast data to an RVP by unicasting. Each 134 receiver joins a multicast group, and a tree rooted from an RVP is 135 created as a result. A receiver is a leaf in the tree. Multicast data 136 received at an RVP is forwarded along the created tree. 138 RVP is described as ``sender'' in the case of a reservation between 139 sender(s) and an RVP, and is described as ``receiver'' in the case of 140 a reservation between an RVP and receiver(s), in this paper. 142 3. Messages 144 The following six messages are used in SRSVP: 145 * KeepALive Message 146 * Resv Message 147 * PathTear Message 148 * ResvTear Message 149 * PathChg Message 150 * ResvChg Message 152 SRSVP messages in BNF notation are shown as follows: 154 KeepAlive = Header 155 Path = Header Dst Src Sspec Label Policy PQ FAQ [ Ref ] 156 Resv = Header Dst Src [ Sspec Label Policy PQ FAQ ] 157 PathTear = Header Dst Src [ Err ] 158 ResvTear = Header Dst Src [ Err ] 159 PathChg = Header Dst Src Ref Chg 160 ResvChg = Header Dst Src Ref Chg 162 Dst 163 Indicates protocol number, destination address and destination 164 port. 166 Src 167 Indicates source address and source port. When Dst is a 168 multicast address, Src can have multiple pairs of source 169 address and source port. 171 Sspec 172 Service Specification 174 Label 175 A label used between adjacent nodes. 177 Policy 178 Indicates region where a sender is charged. 180 PQ 181 PQ. 183 FAQ 184 FAQ. 186 Ref 187 In order to distinguish charge information of each flow. a 188 router, which requiring charging and is the nearest to a 189 sender, attaches Ref to a Path message. 191 Chg 192 Indicates the total sum of charge. 194 Err 195 Error code. 197 3.1 KeepAlive Message 199 A KeepAlive message is used for maintaining TCP connection. 201 3.2 Path Message 203 A Path message MUST include a session, a sender template, Sspec and 204 MAY include FAQ, PQ and policy if needed. A Path is sent from a sender 205 in response to a Resv message. A request from a receiver, i.e. a Resv 206 message, is restricted by a Path message. 208 3.3 Resv Message 210 There are two types of Resv messages. One is for obtaining Sspec, FAQ, 211 PQ and policy, and the other is for actually requesting for a resource 212 reservation. The former is called as Resv0 and the latter is called as 213 Resv1. Resv0 MUST include session and sender template(s). Resv1 MUST 214 include session, sender template(s) and Sspec, and MAY include FAQ and 215 PQ. A Resv message is sent from a receiver. 217 3.4 PathTear/ResvTear Message 219 A PathTear message, which a sender or an RVP sends, and a ResvTear 220 message, which a receiver sends, tear down a resource reservation and 221 notify an error. A sender, an RVP or a receiver explicitly tear down a 222 reservation by a PathTear/ResvTear message, while a sender, an RVP, a 223 receiver or an en-route router tear down a reservation by a 224 PathTear/ResvTear message with an error code. A PathTear/ResvTear MUST 225 include session and sender template(s), and MAY include an object that 226 indicates an error when the error occurs. 228 Types of error objects are as follows: 230 Unreachable Host (UH) 231 Cannot reach a host 233 Unavailable Bandwidth (UB) 234 The bandwidth is unavailable 236 Unsatisfying Delay (UD) 237 The delay does not satisfy a request 239 Unsatisfying Charge (UC) 240 The charge does not satisfy a request 242 Illegal Sspec (IS) 243 The Sspec is illegal. 245 Invalid Policy (IP) 246 The policy is invalid. 248 3.5 PathChg/ResvChg 250 A PathChg and a ResvChg conveys charging information for a flow, and 251 are transfered from a side of a sender to receivers, and from sides of 252 receivers to a sender, respectively. 254 4. Basic Procedure of Making a Resource Reservation 256 The following shows an abstract of a procedure of making a resource 257 reservation. 259 4.1 Abstract of Resource Reservation Procedure 261 1. A receiver sends a Resv message without a Sspec, i.e. Resv0. 262 En-route routers forwards it along the way to a sender, and 263 memorize a state of the flow. 264 2. A sender that received a Resv0 sends a Path message. It is 265 forwarded along the reverse path of Resv0, with being added FAQ 266 and PQs. Each router releases the state of the flow after 267 forwarding the Path. 268 3. The receiver that received the Path sends a Resv message (Resv1) 269 with the received Sspec/Policy/FAQ/PQ. Each of the receiver and 270 en-route routers calculates a QoS path from a sender to itself, 271 and forwards Resv1 along the reverse path of that path, with 272 memorizing a state of the flow. 273 4. The sender that received the Resv1 sends a Path message. It is 274 forwarded along the reverse path of Resv1, with being added FAQ 275 and PQs. Each of the sender and en-route routers adds an entry of 276 the flow, while sending/forwarding the Path. 278 4.2 Differences between Uni-source Flow and Multi-source Flow 280 * Source address and port are considered for identifying a 281 uni-source flow, while they are not for a multi-source flow. 282 * Source address and port are included in an entry for uni-source 283 flow, while they are not for a multi-source flow. 284 * A node looks up a correct Src (RVP), when it receives multiple 285 Resv messages each of which indicates a different source, in the 286 case of a reservation for a multi-source flow. 288 4.3 Valid Period of Resv 290 Though a router memorizes a state of the flow when it receives the 291 flow, it deletes the state unless it receives a corresponding Path 292 within 30 seconds from the reception of the Resv. 294 4.4 Merging Resv Messages 296 A router postpones the process of a Resv until it receives a Path, 297 when it has already received a Resv for the same flow. 299 It forwards a Path message to each direction it has received one of 300 the Resv message, or sends a PathTear message when the Sspec of the 301 Resv does not correspond to the Sspec of the Path, when it received 302 the Path. 304 These procedures mean merging reservations. 306 4.5 Restriction of Reservation by Sender 308 A Resv from a receiver is restricted by a Path of a sender. That is, a 309 sender adds restriction to a reservation. Receivers obeys the 310 restriction. 312 4.5.1 Resv1 Received before Setting Up Reservation 314 A router absolutely trusts Sspec/FAQ/PQ in a Resv and proceeds the 315 reservation, when it receives the Resv before setting up the 316 reservation. 318 4.5.2 Resv1 Received after Setting Up Reservation 320 Assuming that a reservation for the flow is already established when a 321 router receives Resv1. 323 * In the case that the Sspec of the Resv is the same as the Sspec of 324 the Path, the FAQ of the Resv includes that of the Path, and the 325 PQ of the Resv includes that of the Path: 326 The router forwards the Resv1 to the upstream node, which has 327 already established the reservation, as long as the router has not 328 sent a Resv to the upstream node. 329 * In the case that the Sspec of the Resv is different from the Sspec 330 of the Path: 331 The router forwards the Resv0 to the upstream node, which has 332 already established the reservation, as long as the router has not 333 sent a Resv to the upstream node. The router re-receives a Path 334 and compares the Sspec to the Sspec of the Path. The resulting 335 difference means an error. 336 * In the case that the FAQ of the Resv does not include that of the 337 Path, or the PQ of the Resv does not include that of the Path: 338 The router forwards the Resv0 to the upstream node, which has 339 already established the reservation, as long as the router has not 340 sent a Resv to the upstream node. The router re-receives a Path 341 and proceeds the Resv1 with FAQ/PQ in the Path. 343 5. Examples of Reservations 345 The following shows an example of creating a multicast tree. See 346 appendix C for more complicated examples. 348 5.1 Notation 350 Notation is as follows: 352 L(bw=,dly=): 353 Link information. 355 A(chg=): 356 Area information. 358 P(req=,bw=,PQ(...),...): 359 Path message. 361 R(req=,bw=,PQ(...),...): 362 Resv message. 364 PQ(,bw=): 365 PQ. 367 PT(err=): 368 PathTear message. 370 RT(err=): 371 ResvTear message. 373 where: 375 bw=: 376 Bandwidth available at a link or requested by a Resv. 378 dly=: 379 Transmission delay at each link. 381 chg=: 382 Charge when a reservation is established. 384 req=: 385 This specifies a condition for calculating the shortest path 386 tree. This is included in a Sspec or a Sspec. See [SS] for 387 details. 389 : 390 A link, which is written as A1->A2. 392 err= 393 A type of errors. Illegal Sspec (IF) and Unreachable Host (UH) 394 are used here. 396 Note that a ``+'' in a message means succeeds contents of the previous 397 message. 399 5.2 Initial State 401 Consider a network in Figure C.2.1. 403 Assuming that bandwidth or delay at each link is the same as that of 404 the opposite direction for simplicity, though each of them is 405 different from the opposite directions originally. Charging for 406 passing an area is just defined for simplicity, though charging is 407 based on both of incoming direction and outgoing direction originally. 409 S1-----------A1-----------A2-----------A5-----------R1 410 | | | 411 | | | 412 | | | 413 | | | 414 +-----------A3-----------A6-----------R2 415 L(bw=0) |A(chg=2) | 416 | | 417 | | 418 | | 419 P1-----------A4-----------A7 420 L(bw=0) 422 S: Sender bw=1 at every link except A1-A3 and A4-A7 423 R: Receiver dly=1 at every link 424 A: Area chg=1 at every area except A3 425 P: rendezvous Point 427 Figure C.2.1: Initial State 429 5.3 Reservation of Uni-source Flow 431 5.3.1 Reservation of S1->P1 433 Consider that RVP P1 makes a reservation of S1->P1. This reservation 434 is one for a uni-source flow. 436 First, P1 sends Resv0, and each router forwards it along the unicast 437 path towards a sender S1. Each node memorizes the state of the flow at 438 this time. 440 <---------- 441 S1-----------A1-----------A2 442 ^ | | 443 | | | 444 | | | 445 | | | 446 | +-----------A3 447 +------------- | ^ 448 | | 449 | | 450 | | 451 P1-----------A4 452 ----------> 453 R() 455 Figure C.3.1: P1->S1 Resv0 457 S1 sends a Path towards the direction from which it has received a 458 Resv, and each router forwards the Path along the reverse path of 459 Resv0. (Figure C.3.2) The state of the flow is deleted after the Path 460 was sent/forwarded. 462 A FAQ is actually included, but is omitted here. 464 P(req=dly,bw=1) 465 ----------> 466 S1-----------A1-----------A2 467 | | | 468 | | | 469 | | | 470 | | | 471 | +-----------A3 472 +------------> | | 473 | | 474 | | 475 | V 476 P1-----------A4 477 <---------- 479 Figure C.3.2: S1->P1 Path 481 P1 sends a Resv1 with a Sspec same as the Sspec included in the Path. 482 Each router calculates a QoS path from S1 to itself, and forwards the 483 Resv1 along the path reversely. (Figure C.3.3) Each router memorizes a 484 state of the flow. 486 <---------- <---------- 487 S1-----------A1-----------A2 488 | | ^ 489 | | | 490 | | | 491 | | | 492 +-----------A3 493 | ^ 494 | | 495 | | 496 | | 497 P1-----------A4 498 ----------> 499 R(req=dly,bw=1) 501 Figure C.3.3: P1->S1 Resv1 503 A Path is forwarded along the reverse path of Resv1. As each router 504 adds an entry, the reservation is established. The Path includes PQs. 505 (Figure C.3.4) 507 FAQs are also included actually, but are omitted here. 509 P(req=dly,bw=1, 510 PQ(S1->A1,bw=1)) P(+,PQ(A1->A2,bw=1)) 511 ----------> ----------> 512 S1===========A1===========A2 513 | || | 514 | || |P(+,PQ(A2->A3,bw=1)) 515 | || | 516 | || V 517 +-----------A3 518 || | 519 || |P(+,PQ(A3->A4,bw=1)) 520 || | 521 || V 522 P1<==========A4 523 <---------- 524 P(+,PQ(A4->P1,bw=1)) 526 Figure C.3.4: S1->P1 Path with PQ 528 A state of the network is shown in Figure C.3.5, after the reservation 529 is established. 531 L(bw=0) L(bw=0) 532 S1-----------A1-----------A2 533 | | 534 L(bw=0)| L(bw=0)| 535 | | 536 | | 537 +-----------A3 538 | 539 L(bw=0)| 540 | 541 | 542 P1-----------A4 543 L(bw=0) 545 Figure C.3.5: A state after establishment of the reservation 547 5.4 Resource Reservation of Multi-Source Flow 549 5.4.1 Resource Reservation P1->R1 551 Assuming that receiver R1 will make a reservation of a multi-source 552 flow towards RVP P1. First, a reservation is established shown as 553 Figure C.4.1 - C.4.4, same as a unicast resource reservation 555 Note that bandwidth of links P1->A4, A4->A3 and A3->A2 remain as shown 556 in Figure C.2.1, since they are reverse directions of the previously 557 described flow of a unicast resource reservation. 559 R() 560 <--------- 561 A2-----------A5-----------R1 562 | | | 563 | | | 564 | | | 565 | | V 566 A3-----------A6-----------R2 567 | | | 568 | | | 569 | | | 570 | | V 571 P1-----------A4-----------A7 572 <---------- <---------- 574 Figure C.4.1: R1->P1 Resv0 576 ---------> 577 A2-----------A5-----------R1 578 | | ^ 579 | | | 580 | | | 581 | | | 582 A3-----------A6-----------R2 583 | | ^ 584 | | | 585 | | | 586 | | | 587 P1-----------A4-----------A7 588 ----------> ----------> 589 P(req=chg,bw=1) 591 Figure C.4.2: P1->R1 Path 592 R(req=chg, bw=1) 593 <--------- <---------- 594 A2-----------A5-----------R1 595 | | | 596 | | | 597 | | | 598 V | | 599 A3-----------A6-----------R2 600 | | | 601 | | | 602 | | | 603 V | | 604 P1-----------A4-----------A7 605 <---------- 607 Figure C.4.3: R1->P1 Resv1 609 P(+,PQ(A2->A5,bw=1)) P(+,PQ(A5->R1,bw=1)) 610 ---------> ---------> 611 A2===========A5==========>R1 612 ^ || | 613 P(+,PQ(A3->A2,bw=1))| || | 614 | || | 615 | || | 616 A3-----------A6-----------R2 617 ^ || | 618 P(+,PQ(A4->A3,bw=1))| || | 619 | || | 620 | || | 621 P1===========A4-----------A7 622 ----------> 623 P(req=chg,bw=1, 624 PQ(P1->A4,bw=1)) 626 Figure C.4.4: R1->P1 Path with PQ 628 5.5 P1->R2 Resource Reservation 630 Next, the procedure for R2 to make a resource reservation is shown in 631 Figure C.4.5-C.4.8. 633 A2===========A5==========>R1 634 || | 635 || | 636 || | R() 637 ||<---------- |<---------- 638 A3-----------A6-----------R2 639 | || | 640 | || | 641 | || | 642 V || | 643 P1===========A4-----------A7 644 <---------- 646 Figure C.4.5: R2->P1 Resv0 648 A2===========A5==========>R1 649 || | 650 || | 651 || | 652 ||----------> |----------> 653 A3-----------A6-----------R2 654 ^ || | 655 P(+,PQ(A4->A3,bw=1))| || | 656 | || | 657 | || | 658 P1===========A4-----------A7 659 ----------> 660 P(req=chg,bw=1, 661 PQ(P1->A4,bw=1)) 663 Figure C.4.6: P1->R2 Path 665 A2===========A5==========>R1 666 || | 667 || | 668 || | 669 || | 670 A3-----------A6-----------R2 671 | ||<--------- |<---------- 672 R(req=chg,bw=1, | || | R(req=chg,bw=1, 673 PQ(P1->A4,bw=1))| || | PQ(P1->A4,bw=1), 674 V || | PQ(A4->A3,bw=1)) 675 P1===========A4-----------A7 676 <---------- 677 R(req=chg,bw=1) 679 Figure C.4.7: R2->P1 Resv1 681 A2===========A5==========>R1 682 || | 683 || | 684 || | 685 || | 686 A3===========A6==========>R2 687 ^ || ---------> | ---------> 688 P(+,PQ(A4->A3,bw=1))| ||P(+, | P(+,PQ(A6->R2,bw=1)) 689 | || PQ(A3->A6,| 690 | || bw=1)) | 691 P1===========A4-----------A7 692 ----------> 693 P(req=chg,bw=1, 694 PQ(P1->A4,bw=1)) 696 Figure C.4.8: P1->R2 Path 698 6. TCP Connections for Exchanging Messages 700 The way to establish TCP connections for exchanging SRSVP messages. 702 The port number of XXXX is used for TCP connections. Each node 703 searches adjacent nodes from link information of HQLIP, and establish 704 a TCP connection to each of them. The direction of a TCP connection is 705 decided by the way described in [HQLIP]. 707 A node tear down reservations related to the connection, when the 708 connection is cut off. 710 References 712 [RSVP] 713 Braden, R., Zhang, L., Berson, S., Herzog, S. and Jamin, S., 714 ``Resource ReSerVation Protocol (RSVP) -- Version 1 Functional 715 Specification,'' RFC2205, September 1997. 717 [SS] 718 Fujikawa, K., and Sasaki, M., ``Service Specification (SS),'' 719 Internet Draft (work in progress), 720 draft-fujikawa-ric-ss-01.txt, March 2001. 722 [HQLIP] 723 Ohta, M. and Fujikawa, K., ``Hierarchical QoS Link Information 724 Protocol (HQLIP),'' Internet Draft (work in progress), 725 draft-ohta-ric-hqlip-00.txt, March 2001. 727 Authors' Address 729 FUJIKAWA Kenji 730 Graduate School of Informatics 731 Kyoto University 732 Yoshidahonmachi, Sakyo-Ku, Kyoto City, 606-8501, JAPAN 733 Phone: +81-75-753-5387 734 Fax: +81-75-751-0482 735 EMail: fujikawa@real-internet.org 737 SHENG Wei 738 Graduate School of Informatics 739 Kyoto University 740 Yoshidahonmachi, Sakyo-Ku, Kyoto City, 606-8501, JAPAN 741 Phone: +81-75-753-5387 742 Fax: +81-75-751-0482 743 EMail: sheng@kuis.kyoto-u.ac.jp 744 Appendix 746 A. Message Formats 748 A.1 Header 750 +---------------+---------------+---------------+---------------+ 751 | Length | Type | Flags | 752 +---------------+---------------+---------------+---------------+ 754 Length: 16bits 755 The total length of message including the header (byte). 757 Type: 8 bits 758 0 = KeepAlive 759 1 = Path 760 2 = Resv 761 5 = PathTear 762 6 = ResvTear 763 7 = PathChg 764 8 = ResvChg 766 Flags: 4 bits 767 0x1 = Uncharged 768 This bit is valid only for a Resv message. When this bit is 769 set, the flow is not charged and parameters related to charging 770 in Sspec, a path is calculated just according to bandwidth and 771 delay. 773 A.2 Dst 775 IPv4 776 +---------------+---------------+---------------+---------------+ 777 | IPv4 Dst Address | 778 +---------------+---------------+---------------+---------------+ 779 | Dst Port | Protocol Id | 780 +---------------+---------------+---------------+ 782 IPv6 783 +---------------+---------------+---------------+---------------+ 784 | | 785 + + 786 | | 787 + IPv6 Dst Address + 788 | | 789 + + 790 | | 791 +---------------+---------------+---------------+---------------+ 792 | Dst Port | Protocol Id | 793 +---------------+---------------+---------------+ 795 IPv4/IPv6 Dst Address: 32bits or 128bits The IP unicast or multicast 796 destination address of the flow. 798 Dst Port: 8bits 799 The UDP/TCP destination port for the flow. 801 Protocol ID: 8bits 802 The IP Protocol Identifier for the data flow. 804 A.3 Src 806 IPv4 807 +---------------+ 808 | Number | 809 +---------------+---------------+---------------+---------------+ 810 | IPv4 Src Address | 811 +---------------+---------------+---------------+---------------+ 812 | Src Port | Flags | 813 +---------------+---------------+---------------+---------------+ 814 | IPv4 Src Address... 816 IPv6 817 +---------------+ 818 | Number | 819 +---------------+---------------+---------------+---------------+ 820 | | 821 + + 822 | | 823 + IPv6 Src Address + 824 | | 825 + + 826 | | 827 +---------------+---------------+---------------+---------------+ 828 | Src Port | Flags | 829 +---------------+---------------+---------------+---------------+ 830 | | 831 + + 832 | | 833 + IPv6 Src Address... 835 Number: 8bit 836 The number of source address from zero to eight. This number of 837 the tuples below follow. 839 IPv4/IPv6 Src Address: 32bits, 128bits 840 Source Address. 842 Src Port: 16bits 843 Source port. 845 Flags: 4 bits 846 0x1 = Down indicates this host is down. 848 A.4 Sspec 850 +---------------+---------------+---------------+---------------+ 851 // REQ_QOS (See [SS]) // 852 +---------------+---------------+---------------+---------------+ 854 A.5 Label 856 Label defines a label under layer 3. Label must be used from the 857 smallest one excluding zero. When a label is not used, these two 858 parameters must be set to zero. 860 +---------------+---------------+ 861 | Physical Line | 862 +---------------+---------------+---------------+---------------+ 863 | Label | 864 +---------------+---------------+---------------+---------------+ 866 Physical Line: 16bits 867 Physical line number. 869 Label: 32bits 870 Label. 872 A.6 Policy 874 +---------------+---------------+ 875 | Number | 876 +---------------+---------------+---------------+---------------+ 877 // Area (See [HQLIP]) // 878 +---------------+---------------+---------------+---------------+ 879 // (Area repeats) // 880 .............. 882 Number: 16bit 883 The number of areas. This number of Areas follow. 885 A.7 FAQ 887 +---------------+ 888 | Number | 889 +---------------+---------------+---------------+---------------+ 890 // Src Area (See Area in [HQLIP]) // 891 +---------------+---------------+---------------+---------------+ 892 // Dst Area (see Area in [HQLIP]) // 893 +---------------+---------------+---------------+---------------+ 894 // PATH_QOS (See [SS]) // 895 +---------------+---------------+---------------+---------------+ 896 // (the above tuple repeats) // 897 ......................... 899 Number: 8bit 900 The number of FAQs from 0 to 255. This number of FAQs follow. 902 A.8 PQ 904 +---------------+ 905 | Number | 906 +---------------+---------------+---------------+---------------+ 907 // SrcArea (See Area in [HQLIP]) // 908 +---------------+---------------+---------------+---------------+ 909 // DstArea (see Area in [HQLIP]) // 910 +---------------+---------------+---------------+---------------+ 911 // PATH_QOS (See [SS]) // 912 +---------------+---------------+---------------+---------------+ 913 // (the above tuple repeats) // 914 ......................... 916 Number: 8bit 917 The number of PQs from 0 to 255. This number of PQs follow. 919 A.9 Err 921 +---------------+ 922 | Flags | 923 +---------------+ 925 Flags: 8bits 926 0x01 = Unreachable Host (UH) 927 0x02 = Unavailable Bandwidth (UB) 928 0x04 = Unsatisfying Delay (UD) 929 0x08 = Unsatisfying Charge (UC) 930 0x10 = Invalid Sspec (IF) 931 0x20 = Invalid PQ (IP) 933 A.10 Ref 935 IPv4 936 +---------------+---------------+---------------+---------------+ 937 | IPv4 RefAddress | 938 +---------------+---------------+---------------+---------------+ 939 | Reference | 940 +---------------+---------------+---------------+---------------+ 942 IPv6 943 +---------------+---------------+---------------+---------------+ 944 | | 945 + IPv6 RefAddress + 946 | | 947 +---------------+---------------+---------------+---------------+ 948 | Reference | 949 +---------------+---------------+---------------+---------------+ 951 A.11 Chg 953 +---------------+---------------+---------------+---------------+ 954 // CHARGE (See [SS]) // 955 +---------------+---------------+---------------+---------------+