INTERNET DRAFT FUJIKAWA Kenji draft-fujikawa-ric-srsvp-00.txt SHENG I Kyoto University GOTO Yukinori Kyushu University Real Internet Consortium 1 February 1999 Simple Resource ReSerVation Protocol (SRSVP) Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract This draft describes Simple Resource ReSerVation Protocol (SRSVP), which implements multicasting, resource reservation and charging in the Internet. 1. Introduction Simple Resource ReSerVation Protocol (SRSVP) is an extension of Resource ReSerVation Protocol (RSVP) [RSVP], and the purposes of it is as follows: * Multicasting * Resource reservation FUJIKAWA Kenji Expires on 1 June [Page 1] INTERNET DRAFT SRSVP February 2000 * Charging SRSVP creates multicast flows and resource-reserved flows (QoS flows). The state of a QoS flow is hard-state. SRSVP implements both of unicast and multicast resource reservations by a method of receiver-initiated resource reservation. 1.1 Specification of QoS Quality of Services (QoSes) specified by hosts are defined in [SS]. 1.2 Terminology Session A Session is identified by a protocol number, a destination address and a destination port. Sender Template A sender template is identified by a source address and a source port. Flow A flow is a unit of resource reservation. There are two type of flows, a uni-source flow and a multi-source flow. Uni-source flow A flow is identified by a session and a sender template. Currently, a flow is regarded as a uni-source one when the destination address of its session is unicast. Multi-source flow A flow is identified by a session. Currently, a flow is regarded as a multi-source one when the destination address of its session is multicast. Rendezvous Point (RVP) A sender which forwards data in the case of a multi-source flow. It is generally an application gateway, and does not have to be a router. State of a flow State of a flow that a router manages. This includes incoming interfaces of Resv/Path and outgoing interfaces of Resv/Path. Routing Entry The information for forwarding a packet which incomes from a certain interface to a defined interface. An entry of a routing FUJIKAWA Kenji Expires on 1 June [Page 2] INTERNET DRAFT SRSVP February 2000 table. Area Information A router advertises information of addresses and charging as area information. Area information is global. See [HQLIP] for details. Link Information A link links an area to another area. A router advertises a metric and QoS parameters of bandwidth and delay as link information. Link information is global. There are two types of link information, external link information and internal link information. See [HQLIP] for details. Sender Tspec (Tspec) Specification of traffic that a sender specifies. Flowspec Specification of traffic that a receiver requests for. A resource reservation is not established unless Flowspec and Tspec are the same. Path QoS (PQ) A PQ shows link information at a link from the viewpoint of a reservation when the reservation is established. Assuming that a link of 10Kpps/50msec exists, a reservation is 3Kpps/50msec, and the link advertises 8Kpps/100msec as a result. In this case, the PQ shows 10Kpps/50msec is available. A PQ is local for each reservation. First Aggregated QoS (FAQ) Receivers and en-route routers may not get information around a sender or an RVP. A FAQ is a set of calculated QoSes from a sender or an RVP to centers of the areas containing it, and is sent to the receivers and en-route routers. A FAQ is local for each reservation. Policy A policy defined in SRSVP is for charging, and specifies for which areas a sender should pay according to a certain reservation. 1.3 Main Differences from RSVP The main differences between SRSVP and RSVP are: * hard-state, * including a multicast mechanism based on rendezvous points, * including a charging function, FUJIKAWA Kenji Expires on 1 June [Page 3] INTERNET DRAFT SRSVP February 2000 * and having a QoS routing mechanism. SRSVP does not need FilterSpecs in RSVP, since filtering senders can be executed at RVPs. 2. Multicast Model The multicast model of SRSVP is based on RVP like PIM-SM. However, an RVP is generally an application gateway, and does not have to be a router. Distinguishable reservations (flows) are established, between a sender and an RVP, and between an RVP and receivers. A sender can be an RVP. Each sender sends multicast data to an RVP by unicasting. Each receiver joins a multicast group, and a tree rooted from an RVP is created as a result. A receiver is a leaf in the tree. Multicast data received at an RVP is forwarded along the created tree. RVP is described as ``sender'' in the case of a reservation between sender(s) and an RVP, and is described as ``receiver'' in the case of a reservation between an RVP and receiver(s), in this paper. 3. Messages The following six messages are used in SRSVP: * Path Message * Resv Message * PathTear Message * ResvTear Message * PathChg Message * ResvChg Message 3.1 Path Message A Path message MUST include a session, a sender template, Tspec and MAY include FAQ, PQ and policy if needed. A Path is sent from a sender in response to a Resv message. A request from a receiver, i.e. a Resv message, is restricted by a Path message. 3.2 Resv Message There are two types of Resv messages. One is for obtaining Tspec, FAQ, PQ and policy, and the other is for actually requesting for a resource reservation. The former is called as Resv0 and the latter is called as Resv1. Resv0 MUST include session and sender template(s). Resv1 MUST include session, sender template(s) and Flowspec, and MAY include FAQ and PQ. A Resv message is sent from a receiver. FUJIKAWA Kenji Expires on 1 June [Page 4] INTERNET DRAFT SRSVP February 2000 3.3 PathTear/ResvTear Message A PathTear message, which a sender or an RVP sends, and a ResvTear message, which a receiver sends, tear down a resource reservation and notify an error. A sender, an RVP or a receiver explicitly tear down a reservation by a PathTear/ResvTear message, while a sender, an RVP, a receiver or an en-route router tear down a reservation by a PathTear/ResvTear message with an error code. A PathTear/ResvTear MUST include session and sender template(s), and MAY include an object that indicates an error when the error occurs. Types of error objects are as follows: Unreachable Host (UH) Cannot reach a host Unavailable Bandwidth (UB) The bandwidth is unavailable Unsatisfying Delay (UD) The delay does not satisfy a request Unsatisfying Charge (UC) The charge does not satisfy a request Illegal Flowspec (IF) The Flowspec is illegal. Invalid Policy (IP) The policy is invalid. 3.4 PathChg/ResvChg A PathChg and a ResvChg conveys charging information for a flow, and are transfered from a side of a sender to receivers, and from sides of receivers to a sender, respectively. 4. Basic Procedure of Making a Resource Reservation The following shows an abstract of a procedure of making a resource reservation. 4.1 Abstract of Resource Reservation Procedure 1. A receiver sends a Resv message without a Flowspec, i.e. Resv0. En-route routers forwards it along the way to a sender, and memorize a state of the flow. FUJIKAWA Kenji Expires on 1 June [Page 5] INTERNET DRAFT SRSVP February 2000 2. A sender that received a Resv0 sends a Path message. It is forwarded along the reverse path of Resv0, with being added FAQ and PQs. Each router releases the state of the flow after forwarding the Path. 3. The receiver that received the Path sends a Resv message (Resv1) with a Flowspec corresponding to the Tspec and received FAQ/PQs. Each of the receiver and en-route routers calculates a QoS path from a sender to itself, and forwards Resv1 along the reverse path of that path, with memorizing a state of the flow. 4. The sender that received the Resv1 sends a Path message. It is forwarded along the reverse path of Resv1, with being added FAQ and PQs. Each of the sender and en-route routers adds an entry of the flow, while sending/forwarding the Path. 4.2 Differences between Uni-source Flow and Multi-source Flow * Source address and port are considered for identifying a uni-source flow, while they are not for a multi-source flow. * Source address and port are included in an entry for uni-source flow, while they are not for a multi-source flow. * A node looks up a correct sender template, i.e. an RVP, when it receives multiple Resv messages each of which indicates different sender template(s) in the case of a reservation for a multi-source flow. 4.3 Valid Period of Resv Though a router memorizes a state of the flow when it receives the flow, it deletes the state unless it receives a corresponding Path within 30 seconds from the reception of the Resv. 4.4 Merging Resv Messages A router postpones the process of a Resv until it receives a Path, when it has already received a Resv for the same flow. It forwards a Path message to each direction it has received one of the Resv message, or sends a PathTear message when the Flowspec of the Resv does not correspond to the Tspec of the Path, when it received the Path. These procedures mean merging reservations. 4.5 Restriction of Reservation by Sender A Resv from a receiver is restricted by a Path of a sender. That is, a sender adds restriction to a reservation. Receivers obeys the restriction. FUJIKAWA Kenji Expires on 1 June [Page 6] INTERNET DRAFT SRSVP February 2000 4.5.1 Resv1 Received before Setting Up Reservation A router absolutely trusts Flowspec/FAQ/PQ in a Resv and proceeds the reservation, when it receives the Resv before setting up the reservation. 4.5.2 Resv1 Received after Setting Up Reservation Assuming that a reservation for the flow is already established when a router receives Resv1. * In the case that the Flowspec of the Resv is the same as the Tspec of the Path, the FAQ of the Resv includes that of the Path, and the PQ of the Resv includes that of the Path: The router forwards the Resv1 to the upstream node, which has already established the reservation, as long as the router has not sent a Resv to the upstream node. * In the case that the Flowspec of the Resv is different from the Tspec of the Path: The router forwards the Resv0 to the upstream node, which has already established the reservation, as long as the router has not sent a Resv to the upstream node. The router re-receives a Path and compares the Flowspec to the Tspec of the Path. The resulting difference means an error. * In the case that the FAQ of the Resv does not include that of the Path, or the PQ of the Resv does not include that of the Path: The router forwards the Resv0 to the upstream node, which has already established the reservation, as long as the router has not sent a Resv to the upstream node. The router re-receives a Path and proceeds the Resv1 with FAQ/PQ in the Path. 5. Examples of Reservations The following shows an example of creating a multicast tree. See appendix C for more complicated examples. 5.1 Notation Notation is as follows: L(bw=,dly=): Link information. A(chg=): Area information. FUJIKAWA Kenji Expires on 1 June [Page 7] INTERNET DRAFT SRSVP February 2000 P(req=,bw=,PQ(...),...): Path message. R(req=,bw=,PQ(...),...): Resv message. PQ(,bw=): PQ. PT(err=): PathTear message. RT(err=): ResvTear message. where: bw=: Bandwidth available at a link or requested by a Resv. dly=: Transmission delay at each link. chg=: Charge when a reservation is established. req=: This specifies a condition for calculating the shortest path tree. This is included in a Flowspec or a Tspec. See [SS] for details. : A link, which is written as A1->A2. err= A type of errors. Illegal Flowspec (IF) and Unreachable Host (UH) are used here. Note that a ``+'' in a message means succeeds contents of the previous message. 5.2 Initial State Consider a network in Figure C.2.1. Assuming that bandwidth or delay at each link is the same as that of the opposite direction for simplicity, though each of them is different from the opposite directions originally. Charging for FUJIKAWA Kenji Expires on 1 June [Page 8] INTERNET DRAFT SRSVP February 2000 passing an area is just defined for simplicity, though charging is based on both of incoming direction and outgoing direction originally. S1-----------A1-----------A2-----------A5-----------R1 | | | | | | | | | | | | +-----------A3-----------A6-----------R2 L(bw=0) |A(chg=2) | | | | | | | P1-----------A4-----------A7 L(bw=0) S: Sender bw=1 at every link except A1-A3 and A4-A7 R: Receiver dly=1 at every link A: Area chg=1 at every area except A3 P: rendezvous Point Figure C.2.1: Initial State 5.3 Reservation of Uni-source Flow 5.3.1 Reservation of S1->P1 Consider that RVP P1 makes a reservation of S1->P1. This reservation is one for a uni-source flow. First, P1 sends Resv0, and each router forwards it along the unicast path towards a sender S1. Each node memorizes the state of the flow at this time. <---------- S1-----------A1-----------A2 ^ | | | | | | | | | | | | +-----------A3 +------------- | ^ | | | | | | P1-----------A4 ----------> R() FUJIKAWA Kenji Expires on 1 June [Page 9] INTERNET DRAFT SRSVP February 2000 Figure C.3.1: P1->S1 Resv0 S1 sends a Path towards the direction from which it has received a Resv, and each router forwards the Path along the reverse path of Resv0. (Figure C.3.2) The state of the flow is deleted after the Path was sent/forwarded. A FAQ is actually included, but is omitted here. P(req=dly,bw=1) ----------> S1-----------A1-----------A2 | | | | | | | | | | | | | +-----------A3 +------------> | | | | | | | V P1-----------A4 <---------- Figure C.3.2: S1->P1 Path P1 sends a Resv1 with a Tspec same as the Flowspec included in the Path. Each router calculates a QoS path from S1 to itself, and forwards the Resv1 along the path reversely. (Figure C.3.3) Each router memorizes a state of the flow. <---------- <---------- S1-----------A1-----------A2 | | ^ | | | | | | | | | +-----------A3 | ^ | | | | | | P1-----------A4 ----------> R(req=dly,bw=1) Figure C.3.3: P1->S1 Resv1 FUJIKAWA Kenji Expires on 1 June [Page 10] INTERNET DRAFT SRSVP February 2000 A Path is forwarded along the reverse path of Resv1. As each router adds an entry, the revervation is established. The Path includes PQs. (Figure C.3.4) FAQs are also included actually, but are omitted here. P(req=dly,bw=1, PQ(S1->A1,bw=1)) P(+,PQ(A1->A2,bw=1)) ----------> ----------> S1===========A1===========A2 | || | | || |P(+,PQ(A2->A3,bw=1)) | || | | || V +-----------A3 || | || |P(+,PQ(A3->A4,bw=1)) || | || V P1<==========A4 <---------- P(+,PQ(A4->P1,bw=1)) Figure C.3.4: S1->P1 Path with PQ A state of the network is shown in Figure C.3.5, after the reservation is established. L(bw=0) L(bw=0) S1-----------A1-----------A2 | | L(bw=0)| L(bw=0)| | | | | +-----------A3 | L(bw=0)| | | P1-----------A4 L(bw=0) Figure C.3.5: A state after establishment of the reservation 5.4 Resource Reservation of Multi-Source Flow 5.4.1 Resource Reservation P1->R1 FUJIKAWA Kenji Expires on 1 June [Page 11] INTERNET DRAFT SRSVP February 2000 Assuming that receiver R1 will make a reservation of a multi-source flow towards RVP P1. First, a reservation is established shown as Figure C.4.1 - C.4.4, same as a unicast resource reservation Note that bandwidth of links P1->A4, A4->A3 and A3->A2 remain as shown in Figure C.2.1, since they are reverse directions of the previously described flow of a unicast resource reservation. R() <--------- A2-----------A5-----------R1 | | | | | | | | | | | V A3-----------A6-----------R2 | | | | | | | | | | | V P1-----------A4-----------A7 <---------- <---------- Figure C.4.1: R1->P1 Resv0 ---------> A2-----------A5-----------R1 | | ^ | | | | | | | | | A3-----------A6-----------R2 | | ^ | | | | | | | | | P1-----------A4-----------A7 ----------> ----------> P(req=chg,bw=1) Figure C.4.2: P1->R1 Path FUJIKAWA Kenji Expires on 1 June [Page 12] INTERNET DRAFT SRSVP February 2000 R(req=chg, bw=1) <--------- <---------- A2-----------A5-----------R1 | | | | | | | | | V | | A3-----------A6-----------R2 | | | | | | | | | V | | P1-----------A4-----------A7 <---------- Figure C.4.3: R1->P1 Resv1 P(+,PQ(A2->A5,bw=1)) P(+,PQ(A5->R1,bw=1)) ---------> ---------> A2===========A5==========>R1 ^ || | P(+,PQ(A3->A2,bw=1))| || | | || | | || | A3-----------A6-----------R2 ^ || | P(+,PQ(A4->A3,bw=1))| || | | || | | || | P1===========A4-----------A7 ----------> P(req=chg,bw=1, PQ(P1->A4,bw=1)) Figure C.4.4: R1->P1 Path with PQ FUJIKAWA Kenji Expires on 1 June [Page 13] INTERNET DRAFT SRSVP February 2000 5.5 P1->R2 Resource Reservation Next, the procedure for R2 to make a resource reservation is shown in Figure C.4.5-C.4.8. A2===========A5==========>R1 || | || | || | R() ||<---------- |<---------- A3-----------A6-----------R2 | || | | || | | || | V || | P1===========A4-----------A7 <---------- Figure C.4.5: R2->P1 Resv0 A2===========A5==========>R1 || | || | || | ||----------> |----------> A3-----------A6-----------R2 ^ || | P(+,PQ(A4->A3,bw=1))| || | | || | | || | P1===========A4-----------A7 ----------> P(req=chg,bw=1, PQ(P1->A4,bw=1)) Figure C.4.6: P1->R2 Path A2===========A5==========>R1 || | || | || | || | A3-----------A6-----------R2 | ||<--------- |<---------- R(req=chg,bw=1, | || | R(req=chg,bw=1, PQ(P1->A4,bw=1))| || | PQ(P1->A4,bw=1), V || | PQ(A4->A3,bw=1)) P1===========A4-----------A7 FUJIKAWA Kenji Expires on 1 June [Page 14] INTERNET DRAFT SRSVP February 2000 <---------- R(req=chg,bw=1) Figure C.4.7: R2->P1 Resv1 A2===========A5==========>R1 || | || | || | || | A3===========A6==========>R2 ^ || ---------> | ---------> P(+,PQ(A4->A3,bw=1))| ||P(+, | P(+,PQ(A6->R2,bw=1)) | || PQ(A3->A6,| | || bw=1)) | P1===========A4-----------A7 ----------> P(req=chg,bw=1, PQ(P1->A4,bw=1)) Figure C.4.8: P1->R2 Path 6. TCP Connections for Exchanging Messages The way to establish TCP connections for exchanging SRSVP messages. The port number of XXXX is used for TCP connections. Each node searches adjacent nodes from link information of HQLIP, and establish a TCP connection to each of them. The direction of a TCP connection is decided by the way described in [HQLIP]. A node tear down reservations related to the connection, when the connection is cut off. 7. Structure of Messages 7.1 Objects of Messages Each message in SRSVP is defined by the following objects, with BNF. * Common Header: The header attached to every SRSVP message. * SESSION: A session, which is constructed by a source address, a protocol ID and a destination port. * RSVP_HOP: This describes an identifier of the output interface, which FUJIKAWA Kenji Expires on 1 June [Page 15] INTERNET DRAFT SRSVP February 2000 consists of an IP address of the interface and Logical Interface Handler (LIH). * SENDER_TEMPLATE: An IP address of a sender or an RVP. * SENDER_TSPEC: A QoS specified by a sender, which is described by REQ_QOS in [SS]. * FLOWSPEC: A QoS requested for by a receiver. * ERROR_SPEC: This shows a type of errors. * POLICY_DATA: Range where a sender is charged * PQ_INFO: PQs, each of which consists of identifier of a link and available QoS. * FAQ_INFO: FAQs, each of which consists of identifier of a link and available QoS. * CHARGE_INFO: Information for charging. 7.2 Construction of Messages ::= [] []* [] [] ::= []+ [] [] [] ::= [] ::= []+ [] ::= ::= []+ FUJIKAWA Kenji Expires on 1 June [Page 16] INTERNET DRAFT SRSVP February 2000 References [RSVP] Braden, R., Zhang, L., Berson, S., Herzog, S. and Jamin, S., ``Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification,'' RFC2205, September 1997. [SS] Fujikawa, K., ``Service Specification,'' http://www.real-internet.org/draft/draft-ric-ss-00.txt, 1999. [HQLIP] Ohta, M. and Fujikawa, K., ``HQLIP,'' http://www.real-internet.org/draft/draft-ric-hqlip-00.txt, 1999. Authors' Address FUJIKAWA Kenji Graduate School of Informatics Kyoto University Yoshidahonmachi, Sakyo-Ku, Kyoto City, 606-8501, JAPAN Phone: +81-75-753-5387 Fax: +81-75-751-0482 EMail: fujikawa@real-internet.org SHENG I Graduate School of Informatics Kyoto University Yoshidahonmachi, Sakyo-Ku, Kyoto City, 606-8501, JAPAN Phone: +81-75-753-5387 Fax: +81-75-751-0482 EMail: sheng@kuis.kyoto-u.ac.jp FUJIKAWA Kenji Expires on 1 June [Page 17] INTERNET DRAFT SRSVP February 2000 Appendix A. Message Formats A.1 Common Header Format 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-------+-------+---------------+---------------+---------------+ | Ver | Flags | Type | 0 | +-------+-------+---------------+---------------+---------------+ | (reserved) | (reserved) | Length (bytes) | +---------------+---------------+---------------+---------------+ * Ver: 4 bits Protocol version number. This is version 2. * Flags: 4 bits 0x1 = Uncharged This is valid when the message type is Resv. A flow is not charged when this flag is set. Besides, coefficients and restrictions included in Tspec/Flowspec are ignored, and only bandwidth and delay are considered to calculate the shortest path. * Type: 8 bits 1 = Path 2 = Resv 5 = PathTear 6 = ResvTear 7 = PathChg 8 = ResvChg * Length: 16bits The length of a message in bytes, including a common header. A.2 Object Formats Every object consists of one or more 32-bit words with a one- word header, with the following format: 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +---------------+---------------+---------------+---------------+ | Length (bytes) | Class-Num | C-Type | +---------------+---------------+---------------+---------------+ | | // (Object Contents) // | | +---------------+---------------+---------------+---------------+ * Length: 16bits The length of an object in bytes, including an object header. FUJIKAWA Kenji Expires on 1 June [Page 18] INTERNET DRAFT SRSVP February 2000 * Class-Num: 8bits The class number of an object. The following objects are defined: + SESSION + RSVP_HOP + SENDER_TEMPLATE + ERROR_SPEC + SENDER_TSPEC + FLOWSPEC + PQ_INFO + FAQ_INFO + POLICY_DATA + CHARGE_INFO * C-Type: 8bits Object type, unique within Class-Num. A.3 Definition of Objects A.3.1 SESSION Class IPv4/UDP SESSION object: Class = 1, C-Type = 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +---------------+---------------+---------------+---------------+ | IPv4 DstAddress | +---------------+---------------+---------------+---------------+ | Protocol Id | Flags | DstPort | +---------------+---------------+---------------+---------------+ IPv6/UDP SESSION object: Class = 1, C-Type = 2 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +---------------+---------------+---------------+---------------+ | | + + | | + IPv6 DstAddress + | | + + | | +---------------+---------------+---------------+---------------+ | Protocol Id | Flags | DstPort | +---------------+---------------+---------------+---------------+ * DstAddress: 32bits or 128bits The IP unicast or multicast destination address of the session. * Protocol ID: 8bits The IP Protocol Identifier for the data flow. * Flags: 8bits Not defined. * DstPort: 8bits FUJIKAWA Kenji Expires on 1 June [Page 19] INTERNET DRAFT SRSVP February 2000 The UDP/TCP destination port for the session. A.3.2 RSVP_HOP Class IPv4 RSVP_HOP object: Class = 3, C-Type = 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +---------------+---------------+---------------+---------------+ | IPv4 Next/Previous Hop Address | +---------------+---------------+---------------+---------------+ | Logical Interface Handle | +---------------+---------------+---------------+---------------+ IPv6 RSVP_HOP object: Class = 3, C-Type = 2 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +---------------+---------------+---------------+---------------+ | | + + | | + IPv6 Next/Previous Hop Address + | | + + | | +---------------+---------------+---------------+---------------+ | Logical Interface Handle | +---------------+---------------+---------------+---------------+ A.3.3 SENDER_TEMPLATE Class IPv4 SENDER_TEMPLATE object: Class = 11, C-type = 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +---------------+---------------+---------------+---------------+ | IPv4 SrcAddress | +---------------+---------------+---------------+---------------+ | ////// | Flags | SrcPort | +---------------+---------------+---------------+---------------+ FUJIKAWA Kenji Expires on 1 June [Page 20] INTERNET DRAFT SRSVP February 2000 IPv6 SENDER_TEMPLATE object: Class = 11, C-type = 2 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +---------------+---------------+---------------+---------------+ | | + + | | + IPv6 SrcAddress + | | + + | | +---------------+---------------+---------------+---------------+ | ////// | Flags | SrcPort | +---------------+---------------+---------------+---------------+ * SrcAddress: 32bits or 128bits The IP address for a sender. This may indicate an RVP. * Flags: 8bits 0x01 = Failure indicates the sender is not available. * SrcPort: 8bits The UDP/TCP source port for a sender. A.3.4 ERROR_SPEC Class RIC ERROR_SPEC object: Class = 6, C-type = 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +---------------+---------------+---------------+---------------+ | Flags | //// | +---------------+---------------+---------------+---------------+ * Flags: 8bits 0x01 = Unreachable Host (UH) 0x02 = Unavailable Bandwidth (UB) 0x04 = Unsatisfying Delay (UD) 0x08 = Unsatisfying Charge (UC) 0x10 = Invalid Flowspec (IF) 0x20 = Invalid PQ (IP) A.3.5 SENDER_TSPEC Class RIC SENDER_TSPEC object: Class = 12, C-type = 3 Refer to REQ_QOS in [SS] for the format. A.3.6 FLOWSPEC Class RIC FLOWSPEC object: Class = 9, C-type = 3 FUJIKAWA Kenji Expires on 1 June [Page 21] INTERNET DRAFT SRSVP February 2000 Refer to REQ_QOS in [SS] for the format. A.3.7 PQ_INFO Class PQ_INFO object: Class = 16, C-type = 1(IPv4), 2(IPv6) 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +---------------+---------------+---------------+---------------+ // SrcArea (see Area in [HQLIP]) // +---------------+---------------+---------------+---------------+ // DstArea (see Area in [HQLIP]) // +---------------+---------------+---------------+---------------+ // PATH_QOS (See [SS]) // +---------------+---------------+---------------+---------------+ // (the above tuple repeats) // ......................... A.3.8 FAQ_INFO Class FAQ_INFO object: Class = 17, C-type = 1(IPv4), 2(IPv6) 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +---------------+---------------+---------------+---------------+ // SrcArea (see Area in [HQLIP]) // +---------------+---------------+---------------+---------------+ // DstArea (see Area in [HQLIP]) // +---------------+---------------+---------------+---------------+ // PATH_QOS (See [SS]) // +---------------+---------------+---------------+---------------+ // (the above tuple repeats) // ......................... A.3.9 POLICY_DATA Class Charging Range POLICY_DATA object: Class = 14, C-Type = 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +---------------+---------------+---------------+---------------+ // Area (See [HQLIP]) // +---------------+---------------+---------------+---------------+ // (repeats) // ......... A.3.10 CHARGE_INFO Class CHARGE_INFO object: Class = 18, C-type = 1 Refer to CHARGE in [SS] for the format. FUJIKAWA Kenji Expires on 31 May [Page 22]