INTERNET DRAFT FUJIKAWA Kenji draft-fujikawa-ric-srsvp-01.txt SHENG Wei Kyoto University Real Internet Consortium 25 March 2001 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 * Charging FUJIKAWA Kenji Expires on 25 November [Page 1]
INTERNET DRAFT SRSVP March 2001 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 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 protocol number, source address, source port, destination address, and destination port. Currently, a flow is regarded as a uni-source flow when the destination address of its session is unicast. Multi-source flow A flow is identified by protocol number, destination address, and destination port. 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 table. Area Information A router advertises information of addresses and charging as area information. Area information is global. See [HQLIP] for details. Link Information FUJIKAWA Kenji Expires on 25 November [Page 2]
INTERNET DRAFT SRSVP March 2001 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. Service Spec (Sspec) Specification of traffic that sender and receiver specify. A resource reservation is not established when two Sspec's of them match. 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. 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. FUJIKAWA Kenji Expires on 25 November [Page 3]
INTERNET DRAFT SRSVP March 2001 3. Messages The following six messages are used in SRSVP: * KeepALive Message * Resv Message * PathTear Message * ResvTear Message * PathChg Message * ResvChg Message SRSVP messages in BNF notation are shown as follows: KeepAlive = Header Path = Header Dst Src Sspec Label Policy PQ FAQ [ Ref ] Resv = Header Dst Src [ Sspec Label Policy PQ FAQ ] PathTear = Header Dst Src [ Err ] ResvTear = Header Dst Src [ Err ] PathChg = Header Dst Src Ref Chg ResvChg = Header Dst Src Ref Chg Dst Indicates protocol number, destination address and destination port. Src Indicates source address and source port. When Dst is a multicast address, Src can have multiple pairs of source address and source port. Sspec Service Specification Label A label used between adjacent nodes. Policy Indicates region where a sender is charged. PQ PQ. FAQ FAQ. Ref In order to distinguish charge information of each flow. a router, which requiring charging and is the nearest to a sender, attaches Ref to a Path message. FUJIKAWA Kenji Expires on 25 November [Page 4]
INTERNET DRAFT SRSVP March 2001 Chg Indicates the total sum of charge. Err Error code. 3.1 KeepAlive Message A KeepAlive message is used for maintaining TCP connection. 3.2 Path Message A Path message MUST include a session, a sender template, Sspec 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.3 Resv Message There are two types of Resv messages. One is for obtaining Sspec, 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 Sspec, and MAY include FAQ and PQ. A Resv message is sent from a receiver. 3.4 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 FUJIKAWA Kenji Expires on 25 November [Page 5]
INTERNET DRAFT SRSVP March 2001 Unsatisfying Charge (UC) The charge does not satisfy a request Illegal Sspec (IS) The Sspec is illegal. Invalid Policy (IP) The policy is invalid. 3.5 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 Sspec, i.e. Resv0. En-route routers forwards it along the way to a sender, and memorize a state of the flow. 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 the received Sspec/Policy/FAQ/PQ. 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 Src (RVP), when it receives multiple FUJIKAWA Kenji Expires on 25 November [Page 6]
INTERNET DRAFT SRSVP March 2001 Resv messages each of which indicates a different source, 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 Sspec of the Resv does not correspond to the Sspec 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. 4.5.1 Resv1 Received before Setting Up Reservation A router absolutely trusts Sspec/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 Sspec of the Resv is the same as the Sspec 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 Sspec of the Resv is different from the Sspec 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 FUJIKAWA Kenji Expires on 25 November [Page 7]
INTERNET DRAFT SRSVP March 2001 sent a Resv to the upstream node. The router re-receives a Path and compares the Sspec to the Sspec 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=<bandwidth>,dly=<delay>): Link information. A(chg=<charge>): Area information. P(req=<request type>,bw=<bandwidth>,PQ(...),...): Path message. R(req=<request type>,bw=<bandwidth>,PQ(...),...): Resv message. PQ(<link>,bw=<bandwidth>): PQ. PT(err=<error type>): PathTear message. RT(err=<error type>): ResvTear message. where: bw=<bandwidth>: Bandwidth available at a link or requested by a Resv. dly=<delay>: Transmission delay at each link. FUJIKAWA Kenji Expires on 25 November [Page 8]
INTERNET DRAFT SRSVP March 2001 chg=<charge>: Charge when a reservation is established. req=<request type>: This specifies a condition for calculating the shortest path tree. This is included in a Sspec or a Sspec. See [SS] for details. <link>: A link, which is written as A1->A2. err=<error type> A type of errors. Illegal Sspec (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 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 FUJIKAWA Kenji Expires on 25 November [Page 9]
INTERNET DRAFT SRSVP March 2001 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() 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. FUJIKAWA Kenji Expires on 25 November [Page 10]
INTERNET DRAFT SRSVP March 2001 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 Sspec same as the Sspec 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 A Path is forwarded along the reverse path of Resv1. As each router adds an entry, the reservation is established. The Path includes PQs. (Figure C.3.4) FAQs are also included actually, but are omitted here. FUJIKAWA Kenji Expires on 25 November [Page 11]
INTERNET DRAFT SRSVP March 2001 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 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 FUJIKAWA Kenji Expires on 25 November [Page 12]
INTERNET DRAFT SRSVP March 2001 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 25 November [Page 13]
INTERNET DRAFT SRSVP March 2001 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 25 November [Page 14]
INTERNET DRAFT SRSVP March 2001 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 25 November [Page 15]
INTERNET DRAFT SRSVP March 2001 <---------- 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. FUJIKAWA Kenji Expires on 25 November [Page 16]
INTERNET DRAFT SRSVP March 2001 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., and Sasaki, M., ``Service Specification (SS),'' Internet Draft (work in progress), draft-fujikawa-ric-ss-01.txt, March 2001. [HQLIP] Ohta, M. and Fujikawa, K., ``Hierarchical QoS Link Information Protocol (HQLIP),'' Internet Draft (work in progress), draft-ohta-ric-hqlip-00.txt, March 2001. 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 Wei 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 25 November [Page 17]
INTERNET DRAFT SRSVP March 2001 Appendix A. Message Formats A.1 Header +---------------+---------------+---------------+---------------+ | Length | Type | Flags | +---------------+---------------+---------------+---------------+ Length: 16bits The total length of message including the header (byte). Type: 8 bits 0 = KeepAlive 1 = Path 2 = Resv 5 = PathTear 6 = ResvTear 7 = PathChg 8 = ResvChg Flags: 4 bits 0x1 = Uncharged This bit is valid only for a Resv message. When this bit is set, the flow is not charged and parameters related to charging in Sspec, a path is calculated just according to bandwidth and delay. A.2 Dst IPv4 +---------------+---------------+---------------+---------------+ | IPv4 Dst Address | +---------------+---------------+---------------+---------------+ | Dst Port | Protocol Id | +---------------+---------------+---------------+ FUJIKAWA Kenji Expires on 25 November [Page 18]
INTERNET DRAFT SRSVP March 2001 IPv6 +---------------+---------------+---------------+---------------+ | | + + | | + IPv6 Dst Address + | | + + | | +---------------+---------------+---------------+---------------+ | Dst Port | Protocol Id | +---------------+---------------+---------------+ IPv4/IPv6 Dst Address: 32bits or 128bits The IP unicast or multicast destination address of the flow. Dst Port: 8bits The UDP/TCP destination port for the flow. Protocol ID: 8bits The IP Protocol Identifier for the data flow. A.3 Src IPv4 +---------------+ | Number | +---------------+---------------+---------------+---------------+ | IPv4 Src Address | +---------------+---------------+---------------+---------------+ | Src Port | Flags | +---------------+---------------+---------------+---------------+ | IPv4 Src Address... FUJIKAWA Kenji Expires on 25 November [Page 19]
INTERNET DRAFT SRSVP March 2001 IPv6 +---------------+ | Number | +---------------+---------------+---------------+---------------+ | | + + | | + IPv6 Src Address + | | + + | | +---------------+---------------+---------------+---------------+ | Src Port | Flags | +---------------+---------------+---------------+---------------+ | | + + | | + IPv6 Src Address... Number: 8bit The number of source address from zero to eight. This number of the tuples below follow. IPv4/IPv6 Src Address: 32bits, 128bits Source Address. Src Port: 16bits Source port. Flags: 4 bits 0x1 = Down indicates this host is down. A.4 Sspec +---------------+---------------+---------------+---------------+ // REQ_QOS (See [SS]) // +---------------+---------------+---------------+---------------+ FUJIKAWA Kenji Expires on 25 November [Page 20]
INTERNET DRAFT SRSVP March 2001 A.5 Label Label defines a label under layer 3. Label must be used from the smallest one excluding zero. When a label is not used, these two parameters must be set to zero. +---------------+---------------+ | Physical Line | +---------------+---------------+---------------+---------------+ | Label | +---------------+---------------+---------------+---------------+ Physical Line: 16bits Physical line number. Label: 32bits Label. A.6 Policy +---------------+---------------+ | Number | +---------------+---------------+---------------+---------------+ // Area (See [HQLIP]) // +---------------+---------------+---------------+---------------+ // (Area repeats) // .............. Number: 16bit The number of areas. This number of Areas follow. A.7 FAQ +---------------+ | Number | +---------------+---------------+---------------+---------------+ // Src Area (See Area in [HQLIP]) // +---------------+---------------+---------------+---------------+ // Dst Area (see Area in [HQLIP]) // +---------------+---------------+---------------+---------------+ // PATH_QOS (See [SS]) // +---------------+---------------+---------------+---------------+ // (the above tuple repeats) // ......................... Number: 8bit The number of FAQs from 0 to 255. This number of FAQs follow. FUJIKAWA Kenji Expires on 25 November [Page 21]
INTERNET DRAFT SRSVP March 2001 A.8 PQ +---------------+ | Number | +---------------+---------------+---------------+---------------+ // SrcArea (See Area in [HQLIP]) // +---------------+---------------+---------------+---------------+ // DstArea (see Area in [HQLIP]) // +---------------+---------------+---------------+---------------+ // PATH_QOS (See [SS]) // +---------------+---------------+---------------+---------------+ // (the above tuple repeats) // ......................... Number: 8bit The number of PQs from 0 to 255. This number of PQs follow. A.9 Err +---------------+ | Flags | +---------------+ Flags: 8bits 0x01 = Unreachable Host (UH) 0x02 = Unavailable Bandwidth (UB) 0x04 = Unsatisfying Delay (UD) 0x08 = Unsatisfying Charge (UC) 0x10 = Invalid Sspec (IF) 0x20 = Invalid PQ (IP) A.10 Ref IPv4 +---------------+---------------+---------------+---------------+ | IPv4 RefAddress | +---------------+---------------+---------------+---------------+ | Reference | +---------------+---------------+---------------+---------------+ FUJIKAWA Kenji Expires on 25 November [Page 22]
INTERNET DRAFT SRSVP March 2001 IPv6 +---------------+---------------+---------------+---------------+ | | + IPv6 RefAddress + | | +---------------+---------------+---------------+---------------+ | Reference | +---------------+---------------+---------------+---------------+ A.11 Chg +---------------+---------------+---------------+---------------+ // CHARGE (See [SS]) // +---------------+---------------+---------------+---------------+ FUJIKAWA Kenji Expires on 25 November [Page 23]