idnits 2.17.1 draft-ghani-odsi-cops-00.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 Internet-Drafts being working documents -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 692 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 an Authors' Addresses Section. ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 4 instances of too long lines in the document, the longest one being 2 characters in excess of 72. ** There are 8 instances of lines with control characters in the document. == There are 4 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- 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 (July 5, 2000) is 8668 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) == Outdated reference: A later version (-05) exists of draft-ietf-rap-pr-02 ** Downref: Normative reference to an Historic draft: draft-ietf-rap-pr (ref. 'Ref2') -- Possible downref: Non-RFC (?) normative reference: ref. 'Ref3' -- Possible downref: Non-RFC (?) normative reference: ref. 'Ref4' -- Possible downref: Non-RFC (?) normative reference: ref. 'Ref5' -- Possible downref: Normative reference to a draft: ref. 'Ref7' ** Obsolete normative reference: RFC 2401 (ref. 'Ref8') (Obsoleted by RFC 4301) Summary: 10 errors (**), 0 flaws (~~), 5 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Draft N. Ghani 2 Expiration: January 2001 Sorrento Networks 3 File: draft-ghani-odsi-cops-00.txt Z. Zhang 4 Sorrento Networks 5 L. Zhang 6 Sorrento Networks 7 J. Fu 8 Sorrento Networks 10 COPS Usage for ODSI 12 July 5, 2000 14 Status of this Memo 16 This document is an Internet-Draft and is in full conformance with all 17 provisions of Section 10 of RFC2026. 19 Internet-Drafts are working documents of the Internet Engineering Task 20 Force (IETF), its areas, and its working groups. Note that other 21 groups ay also distribute working documents as Internet-Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference material 26 or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 Distribution of this memo is unlimited. 36 Copyright Notice 38 Copyright (C) The Internet Society (2000). All Rights Reserved. 40 Abstract 42 ODSI is a framework of protocols designed to allow internetworking 43 devices to dynamically request bandwidth from optical networks. Within 44 this framework, a protocol is required for policy provisioning inside 45 the optical domain. This documents defines the application of the IETF 46 Common Open Policy Service (COPS) protocol for this purpose and details 47 its interworking with the ODSI framework. 49 1. Introduction 51 The IETF Common Open Policy Service (COPS) protocol is a well-defined 52 policy provisioning protocol. Owing to its generic specification, COPS 53 can also be applied within the optical networks space for 54 authentication and resource control functions. This is a crucial 55 requirement for optical networks and will allow operators to 56 specifically engineer policies to meet their operational requirements. 57 Along these lines, this document describes the application of the COPS 58 protocol within the ODSI framework. A brief introduction to the COPS 59 protocol is first presented, and subsequently, its interworking with 60 the ODSI protocols framework is detailed. 62 2. Review of the COPS Protocol 64 A very brief outline of the COPS protocol framework is first given. 65 However, this summary is only intended to serve as a background 66 reference, and interested readers are referred to the various protocol 67 specification documents [Ref1, Ref2,Ref6] for full details. 69 2.1 Functional Overview 71 COPS is a query/response protocol based upon a client/server model and 72 has been designed for policy and admission control for a generic set of 73 network resources. Although it is being developed by the IETF RAP 74 (Resource Allocation Protocol) group, owing to its inherently 75 generalized design, it can clearly be applied under a much broader 76 context. The framework defines client entities, termed Policy 77 Enforcement Points (PEPs), and server entities, termed Policy Decision 78 Points (PDPs), which exchange policy information through various 79 message types. At least one PDP entity has to be defined for an 80 administrative domain. The messages include request, update, and 81 delete messages from the PEP and decision and update messages from the 82 PDP server (see Section 2.2 also). COPS has been designed to support 83 multiple policy clients [Ref2], and examples include quality of service 84 (QOS), security, customer-specific, etc. Therefore, to distinguish 85 between different client types, a client type must be specified in each 86 message. Each client type can have its own specific data and policy 87 decision rules. Note that a single PEP or PDP can support policy 88 provisioning for multiple client types. 90 +-----------------+ 91 | Network Node | Policy Server 92 | +-----+ | COPS +-----+ 93 | | PEP |<------+----------->| PDP | 94 | +-----+ | +-----+ 95 | ^ | 96 | | +------+ | 97 | +->| LPDP | | 98 | +------+ | 99 +-----------------+ 101 Figure 1: A COPS illustration (from [Ref1]). 103 The overall interaction between the respective COPS protocol entities 104 is shown in Figure 1 (from [Ref1]). Specifically, the COPS protocol 105 message set details the information exchange between the client PEP 106 and remote PDP server. Additionally, an optional Local Policy Decision 107 Point (LPDP) entity can also be associated with a network device to 108 execute "local" policy decisions. However, all local decision 109 information must be relayed to the PDP also (i.e., by the PEP in the 110 form of an LPDP decision object), and the PDP entity remains as the 111 binding decision point for all PEP requests. A PEP client communicates 112 with its PDP server to implement various policy decision frameworks. 113 As a network client, the PEP initiates this communication by opening a 114 persistent (two-way) TCP connection to the PDP, and this connection is 115 used for all communications between these two entities. TCP is chosen 116 due to the important nature of the policy control information carried. 117 This choice precludes the need for any additional mechanisms for reliable 118 communication. 120 COPS can function in two basic models, outsourcing and provisioning 121 [Ref2] and defines various objects for its functioning, see [Ref1]. 122 n the outsourcing model represents a client-driven approach, where the 123 PDP server actively responds to incoming policy requests from PEP 124 clients. This model works well for signaled protocols, e.g., as in 125 RSVP-COPS [Ref6]. Client requests are carried via COPS-PR defined data 126 objects, which communicate Client Specific Information objects [Ref7]. 127 The format of this data is independent of the actual messaging protocol, 128 and hence this decouples the information model from the actual signaling 129 semantics. For example, RSVP-COPS requires all RSVP Path message data 130 to be directly encapsulated into associated COPS message types (see 131 [Ref6] for details). Examples of various RSVP PEP-PDP message exchange 132 sequences are also detailed in [Ref6]. 134 Meanwhile, the provisioning model represents a server-driven approach, 135 where the PDP downloads (pre-provisions) policy information to client 136 PEPs beforehand. Such policy information is based upon predicted 137 configurations/demands and works well for non-signaled protocols/ 138 scenarios. Specifically, after the PEP-PDP connection is setup, the 139 PEP sends a configuration request message to the PDP, which in turn 140 replies with a message containing all provisionable policies for the 141 PEP device. Alternatively, the PDP can also asynchronously "push" 142 policy state onto the PEP. Meanwhile, the actual COPS policy data is 143 represented via a named "self-identifying" data structure, termed the 144 Policy Information Base (PIB) [Ref2]. This structure specifies the 145 type and purpose of the policy information arriving from the PDP, and 146 hence must also be client specific. This information is installed by 147 the PEP. Conceptually, PIB can be described using a tree structure, 148 consisting of Policy Rule Classes (PRCs) and their associated Policy 149 Rule Instances (PRIs), see [Ref2]. The overall PIB concept is very 150 flexible, and the class/rule definitions can be further modified between 151 PEP/PDP nodes to reflect new policy requirements, e.g., expiration 152 quotas, time-of-day restrictions, and other SLA details (see [Ref2]). 153 In the provisioning model, the PDP can re-issue updated policies to 154 PEPs at any time, i.e., asynchronous updates. After any installation/ 155 deletion of such configuration data from the PDP, PEP nodes must send 156 appropriate report messages to the PDP for accounting and monitoring 157 purposes. 159 COPS relies upon a state-based model, where the request/decision state 160 is shared between the PEP and PDP. Specifically, PEP requests are 161 stored on the PDP until explicitly deleted (signaled) from the PEP. 162 These stored requests can have an impact on how the PDP servers process 163 future requests (i.e., based upon current request/decision states). 164 PEP clients whose request states change must notify their PDP servers 165 to the effect and delete non-applicable state information. However, 166 PDP servers can also issue unsolicited messages (e.g., state updates) to 167 PEP clients in order to force existing states. This may be necessary 168 during policy upgrades or SLA changes. Depending upon the client type, 169 multiple states can be installed for a single PEP/PDP relationship (as 170 identified by the Handle object). 172 Due to the important role of the COPS protocol, fault-tolerance 173 features are also provided. These capabilities allow to 174 "re-synchronize" state between the PEP and PDP in the event of a 175 communications failure. The PEP-PDP connection is constantly verified 176 using keep-alive messages, and upon failure detection, the PEP falls 177 back to local decisions (via an LPDP). While disconnected from the 178 PDP, the PEP tries to reconnect to the original PDP and/or to an 179 alternative PDP [Ref1]. Upon connection re-establishment, the PEP must 180 provide the PDP with new state and/or event information. Furthermore, 181 the PDP can resynchronize all the PEP's internal state. See [Ref2] also 182 for additional details on fault tolerance. Finally, security provisions 183 for COPS are provided via an Integrity object, and all COPS 184 implementations must support this object. Additionally, client (PEP) 185 and server (PDP) entities can also use IP Security [Ref8] mechanisms to 186 authenticate and secure the communications channel between the PEP and 187 the PDP entities, as described in [Ref1]. 189 2.2 Message Set Summary 191 A very brief summary of the COPS message set is presented to give a 192 high-level view of some of the protocol's internals. Interested 193 readers are referred to [Ref1],[Ref2] for more details: 195 o Request (REQ) (PEP-to-PDP): PEPs send REQ messages to request policy 196 provisioning data from the PDP. This message includes client-specific 197 information to assist the PDP and also a unique Client Handle (to 198 identify request states at the PEP and PDP entities). 200 o Decision (DEC) (PDP-to-PEP): PDPs respond to client REQ messages 201 via DEC messages. These messages contain multiple policy decisions that 202 are to be installed on the PEP. DEC messages can be used to delete/ 203 update existing rules (i.e., state) in the PEP. DEC messages use the 204 lient Handle to identify the REQ being responded to. These messages 205 contain command codes which instruct various operations on client- 206 specific PIB entities. 208 o Report State (RPT) (PEP-to-PDP): This message is sent from the PEP 209 to the PDP to report accounting information. Also, a PEP must always 210 report back to the PDP the outcome of action taken for an earlier DEC 211 (install) message, i.e., indicating success or failure in applying the 212 configuration action [Ref1]. 214 o Delete Request State (DRQ) (PEP-to-PDP): This message is sent to 215 the PDP in order to delete a request (or related information) 216 pertaining to the specified Client Handle. PEPs can issue DRQ messages 217 in response to status changes on their end (e.g., connection requests 218 withdrawn by clients), and the PDP will take appropriate actions to 219 remove state. It is important for PEPs to issue this command to ensure 220 state consistency with the PDP. 222 o Synchronize State Request (SSQ) (PDP-to-PEP): This message requests 223 the PEP to re-send state information. The Client Handle field here is 224 optional, and if specified, only the respective state needs be conveyed 225 (via a PEP RPT message). If, however, no Client Handle is specified, 226 the PEP must send all its state information to the PDP. 228 o Client-Open (OPN) (PEP-to-PDP): This message is sent to the PDP 229 server to specify various PEP-related information: client-types 230 supported, last PDP connected to per client type, etc. Multiple such 231 messages can be sent at anytime. PEP clients normally send an OPN 232 message after connection establishment with a PDP server. 234 o Client-Accept (CAT) (PDP-to-PEP): In response to the PEP OPN 235 message, the PDP can respond "positively" with a CAT message. This 236 reply contains various timer values which are used to generate keep- 237 alive and/or accounting report messages. 239 o Client-Close (CC) (PEP-to-PDP, PDP-to-PEP): This is a bi- 240 directional message and indicates that a particular client type is no 241 longer supported. This can be sent from the PDP in response to a PEP 242 OPN message, in which case an alternative PDP server may also 243 be specified. 245 o Keep-Alive (KA) (PEP-to-PDP, PDP-to-PEP): These messages are 246 transmitted by the PEP in order to maintain the PEP-PDP connection 247 (i.e., independent of any particular client-type). Associated timer 248 values for this message are specified by the PDP (e.g., via CAT 249 response). The PDP must echo a keep-alive ACK message per incoming 250 PEP keep-alive message. 252 o Synchronize State Complete (SSC) (PEP-to-PDP): This message is sent 253 by the PEP after receiving a PDP SSQ message, and indicates that 254 (state) synchronization between the PEP and PDP is complete. This 255 message may or may not include a Client Handle (as per the original PDP 256 SSQ request message). 258 3. COPS Applied to the ODSI Framework 260 Clearly, COPS provides a very generic policy control framework that is 261 very extensible to the optical networking domain. With recent trends 262 towards IP-based control for optical networks, the use of this 263 framework will further provide for a more seamless interworking with 264 P-controlled devices. Moreover, the built-in reliability and security 265 features of this protocol ensure its applicability to robust services- 266 provisioning scenarios. Hence, it is logical to interwork the COPS and 267 ODSI frameworks together in order to provide a comprehensive policy 268 provisioning setup for optical networks and extend optical policy 269 provisioning closer to the network edge. In particular, the ODSI 270 interface on edge optical devices must communicate with a COPS PEP 271 entity in order to relay policy provisioning request/responses 272 messages. Since the PEP deals with optical network policy 273 administration, it must reside in an edge optical device. This overall 274 framework is illustrated more clearly in Figure 2, where the PEP client 275 communicates with the ODSI interface. 277 +---------------------+ 278 +-------------+ | Edge optical node | 279 | User Device | | | Policy Server 280 | +-------+ | | +-------+-----+ | +-----+ 281 | | ODSI |<-+--------+-->| ODSI | PEP |<--+------>| PDP | 282 | | Int. | | ODSI | | Int. | | | COPS +-----+ 283 | +-------+ | mesgs | +--+----+--^--+ | mesgs 284 | | | | | 285 +-------------+ | | | 286 | +---v--+ | 287 | | LPDP | | 288 | +------+ | 289 +---------------------+ 291 Figure 2: COPS applied to the ODSI framework 293 Initially, the ODSI user device-to-optical interface is setup by a 294 series of procedures (service discovery, address registration, 295 signaling, see [Ref3],[Ref4],[Ref5]). After this procedure is 296 complete, the COPS startup procedures can be initiated. In the above 297 interworking, the ODSI interface residing in the edge optical device 298 passes messaging between the (optical domain) PEP and the (electronic 299 domain) user device, e.g., such as an IP router or SONET digital cross- 300 connect. In particular, this entity translates ODSI actions into 301 appropriate PEP client actions. Subsequently, the optical PEP entity 302 sends back appropriate reply messages to the ODSI interface. Here, the 303 outsourcing policy management model is applied for COPS-ODSI 304 interworking (akin to RSVP-COPS interworking [Ref6]), and ODSI actions 305 are transmitted to the PDP via the local PEP entities. In this case, 306 the PDP (LPDP) returns policy responses to the PEP, which are in turn 307 translated into appropriate ODSI interface actions and/or messages. 308 Therefore, when PEPs open communications with PDP servers, their 309 initial Client-Open (OPN) messages have the client-type set to indicate 310 a signaled client. In particular, a new signaled client type ODSI is 311 defined. If the PDP supports this client-type, it responds with a 312 Client-Accept (CAT) message or otherwise with a Client-Close (CC) 313 message. Alternatively, the PDP can also redirect the PEP to other 314 PDPs in the network domain (via a Redirect address in the CC message). 315 After receiving a CAT message, the PEP can issue the first (ODSI-driven) 316 request message to the PDP server. 318 Meanwhile, the information transfer model assumes that all objects 319 received in the ODSI messages are encapsulated in a Client Specific 320 Information Object (Signaled ClientSI) and sent from the PEP to the 321 PDP. Specifically, ODSI trail request messages will contain 322 topological information (source, destination IP addresses and port 323 numbers), bandwidth requirements, protection levels, preemption 324 priorities, and setup priority. It assumed that the (ODSI policy 325 server) PDP is fully ODSI-aware and can handle these message contents 326 and generate appropriate policy control decisions. 328 ODSI clients are divided into user groups, and bandwidth creation is 329 strictly restricted to (client) user devices belonging to the same OSDI 330 user group [Ref5]. In particular, "admission control" is applied based 331 upon the user group and requester and endpoints (as per functional 332 specification [Ref1]). Hence, when fielding bandwidth requests, ODSI 333 components must first resolve the IP addresses of the endpoints and 334 resolve the associated user group value. This information, along with 335 the details of the ODSI bandwidth request is then forwarded to the 336 COPS policy server (i.e., optical network PDP), which will perform the 337 necessary policy provisioning and accounting procedures on the request. 338 Also note that the ODSI specification states that (electronic client) 339 endpoints may be partially specified [Ref3]. By this it is meant that 340 the complete endpoint information may not be given (i.e., port 341 numbers). However, the endpoint IP addresses are always specified, 342 and user group identification should be possible with this 343 information alone. 345 As per the ODSI signaling specification [Ref4], the request is 346 propagated from (trail) requester to (trail) head to (trail) tail, and 347 then to an optical network controller (ONC) entity. The ONC validates 348 the request and subsequently allocates the resources for the circuit. 349 Now clearly, one of these ODSI entities must initiate policy 350 provisioning via COPS. To functionally decouple the ODSI and COPS 351 entities, it is felt here that such policy requests are best done by 352 the trail head entity, i.e., PEP entity in Figure 2 only provisions 353 policy for electronic client nodes connected to its optical device. 354 Since this point in the network will source the request, it is logical 355 for the PEP entity associated with the trail head to request policy 356 clearance from the network PDP server. If the policy requirements are 357 valid, the request can be further propagated to the trail tail. 358 Otherwise, the request must be rejected (by sending an ODSI trail 359 notification message to the trail requester). In the case the trail 360 head does not have ODSI-COPS interworking (i.e., no PEP entity), the 361 request must again be rejected. In the following section, the 362 message format will be specified in more details. 364 4. Message Contents 366 The COPS protocol provides the capability for different COPS clients 367 to define their own "named", i.e. client-specific, information for 368 various messages. This section describes the messages exchanged between 369 a COPS server (PDP) and COPS ODSI clients (PEP) that carry client- 370 specific data objects. Since ODSI is a signaled client, a new signaled 371 client-type value is defined (TBD) for the common header field. 373 4.1. Request (REQ) PEP -> PDP 375 The REQ message is sent by COPS-ODSI clients to issue a 'Trail Request' 376 to the PDP. The Trail Request REQ is used to request a new trail, to 377 modify or non-destructively modify a previously established trail, 378 to query and to release a trail. The Client Handle associated with the 379 EQ message originated by a client must be unique for that client. 380 he Client Specific info object is used to specify the requested 381 resources and the request identifier. 383 Each REQ message contains a single request. The PDP responds to the 384 resource allocation request with a DEC message containing the answer to 385 the query. The REQ message has the following format: 387 ::= 388 389 390 [] 391 [] 392 [] 394 The only ODSI message type supported by COPS is Trail Create Request 395 (actions: create, destroy, query, modify, indicated by the 396 _action indicator flag_). The other two ODSI messages, Trail Create 397 Acknowledge and Trail Notification, are not supported by COPS. 399 All objects that were received in the ODSI Trail Create Request are 400 encapsulated inside the Client Specific Information (ClientSI) Object 401 sent from PEP to the remote PDP. 403 406 If the request is a Modify request, the previous value for starting 407 time should be appended at the end of ClientSI object (for accounting 408 purpose): 410 :: Request ID 411 Trail Create Request ODSI message 412 (new value) 413 (old value) 415 The LPDPDecision can be specified if applicable. 417 4.2. Decision (DEC) PDP -> PEP 419 The DEC message is sent from the PDP to a COPS-ODSI client in response 420 to the REQ message received from the PEP. Unsolicited DEC messages 421 cannot be sent for this client type (therefore the solicited decision 422 flag is always set). The Client Handle must be the same Handle that 423 was received in the REQ message. 425 PDP performs admission control for Trail Create Request based on the 426 User Group Id, and some other criteria. The Decision object will 427 contain in the Client Specific info the Request ID, which is needed by 428 the PEP to correlate the reply with the query. Each DEC message 429 contains a single decision. The DEC message for the COPS-ODSI client 430 type has the following format: 432 ::= 433 434 | 435 [] 437 The decision object in turn has the following format: 439 ::= 440 441 443 The context object will be the same as contained in the REQ message. 444 The Decision: Flags object will contain the answer in the Command-code 445 field according to the COPS specifications. In particular the Command- 446 code will be "Install" to mean a positive answer and "Remove" to mean 447 a negative answer. The following text clarifies how Install and Remove 448 Decisions map into the different request types. 450 REQ (_action_indicator flag_ = Add) 451 DEC (Dec Flag = Install) -> The requested resources are 452 successfully allocated 454 DEC (Dec Flag = Remove) -> The requested resources are not 455 allocated 457 REQ (_action_indicator flag_ = Release) 459 DEC (Dec flag = Install) -> The resources are released 461 DEC (Dec Flag = Remove) -> The resources are still allocated. 463 REQ (_action_indicator flag_ = Modify) 465 DEC (Dec flag = Install) -> The modification is accepted. The 466 newly requested resources are 467 allocated, while the previous ones 468 have been released 470 DEC (Dec Flag = Remove) -> The modification is not accepted. 471 Previous allocation is still active. 473 REQ (_action_indicator flag_ = Query) 475 DEC (Dec flag = Install) -> The request for query is accepted. 477 DEC (Dec Flag = Remove) -> The request for query is not accepted. 479 The Error object is used to communicate COPS protocol error to the PEP, 480 according to the definition in [Ref1]. No client specific error sub- 481 codes are used by COPS-ODSI. 483 The Decision ClientSI data object carries the information needed to 484 correlate the decision with the answer and some optional information to 485 explain negative Decisions. It has the following format: 487 ::= 488 490 Possible reasons are: 491 Resource unavailable 492 Unsupported resource type 493 Unacceptable source address 494 Unacceptable destination address 496 No report is sent by the PEP to confirm the reception of a Decision 497 message. Only in case of specific errors, the PEP will send back a 498 Report State message to the PDP. 500 4.3. Report State (RPT) PEP -> PDP 502 For COPS-ODSI client type, the Report State message is sent by the PEP 503 to the PDP in case of problems with a received Decision message. More 504 specifically it is used to communicate that the Decision contains a 505 Request identifier which cannot be correlated to a previous request. 506 This event is the manifestation of abnormal behavior. On reception of 507 a Report State message the PDP could start a Synchronization procedure. 508 The RPT message for the COPS-ODSI client type has the following format: 510 ::= 511 512 513 514 [] 516 4.4. Synchronize State Request (SSQ) PDP -> PEP 518 The Synchronize State Request message is sent by the PDP to the PEP to 519 "reset" the state information. It requests the PEP to send the set of 520 resource allocation REQ messages needed to rebuild the state. The SSQ 521 can apply to the whole set of PEP active reservations PEP, or to a 522 specific resource type and source-destination couple, depending on the 523 nformation contained in the Client SI object. 525 < Synchronize State> ::= 526 527 ] 528 [] 530 4.5. Synchronize State Complete (SSC) PEP -> PDP 532 The Synchronize State Complete message is sent by the PEP to the PDP to 533 inform that all the REQ messages needed to rebuild the state have been 534 sent. The Client SI object is the same received in the SSQ message and 535 specifies the scope of the synchronization procedure which has been 536 completed. 538 < Synchronize State Complete> ::= 539 540 ] 541 [] 543 5. Illustrative Examples 545 In this section, some illustrative examples for the COPS-ODSI client 546 interworking are presented. In the first example, the trail request is 547 successful, and in the second example the request is rejected. 549 A PEP requests an OC48 trail between Head (192.234.124.1) and 550 Tail (192.234.4.1). 552 PEP -- > PDP REQ: = 553 554 565 The PDP accepts the request. 567 PDP--- > PEP DEC: = 568 569 570 574 In the following example, the trail request of an OC192 between Head 575 (192.234.1244.1) and Tail (192.234.4.1) is rejected. The same handle 576 and user group are used but the Request ID is different. 578 PEP -- > PDP REQ: = 579 580 591 PDP--- > PEP DEC: = 592 593 594 599 5. References 601 [Ref1] Durham, D., Boyle, J., R. Cohen, S. Herzog, R. Rajan, 602 A. Sastry, "The COPS (Common Open Policy Service) 603 Protocol", IETF RFC 2748, January 2000. 605 [Ref2] Chan, K., Durham, D., Gai, S., Herzog, S., McCloghrie, 606 K., Reichmeyer, F., Seligson, J., Smith, A., Yavatkar, R., 607 "COPS Usage for Policy Provisioning", IETF Draft 608 draft-ietf-rap-pr-02.txt, March 10, 2000. 610 [Ref3] ODSI Coalition, G. Bernstein, R. Coltun, J. Moy and A. 611 Sodder, editors, "Optical Domain Service Interconnect 612 (ODSI) Functional Specification", March 2000. 614 [Ref4] Bernstein, G., Coulton, R., Moy, J., Sodder, A., 615 "Optical Domain Service Interconnect (ODSI) Signaling 616 Specification", April 2000. 618 [Ref5] Bernstein, G., Coulton, R., Moy, J., Sodder, A., 619 Arvind, K., "ODSI Service Discovery and Address 620 Registration," April 2000. 622 [Ref6] Herzog, S., Boyle, J., Cohen, R., Durham, D., Rajan, 623 R., Sastry, A., "COPS Usage for RSVP," IETF RFC 2749, 624 January 2000. 626 [Ref7] Durham, D., Khosravi, H., Weiss, W., Avri, D., "COPS 627 Usage for AAA," IETF Draft draft-durham-aaa-cops-ext-00.txt, 628 May 2000. 630 [Ref8] Atkinson, R., "Security Architecture for the Internet 631 Protocol", RFC 2401, August 1995. 633 6. Authors' Information 635 Nasir Ghani 636 Sorrento Networks Inc., 637 9990 Mesa Rim Road 638 San Diego, CA 92121 639 Phone: (858) 646-7192 640 Email: nghani@sorrentonet.com 642 Zhensheng Zhang 643 Sorrento Networks Inc., 644 9990 Mesa Rim Road 645 San Diego, CA 92121 646 Phone: (858) 646-7195 647 Email: zzhang@sorrentonet.com 649 Leah Zhang 650 Sorrento Networks Inc., 651 9990 Mesa Rim Road 652 San Diego, CA 92121 653 Phone: (858) 450-4977 654 Email: leahz@sorrentonet.com 656 James Fu 657 Sorrento Networks Inc., 658 9990 Mesa Rim Road 659 San Diego, CA 92121 660 Phone: (858) 450-4924 661 Email: jfu@sorrentonet.com 663 7. Full Copyright Notice 665 Copyright (C) The Internet Society (1997). All Rights Reserved. 667 This document and translations of it may be copied and furnished to 668 others, and derivative works that comment on or otherwise explain it 669 or assist in its implementation may be prepared, copied, published 670 and distributed, in whole or in part, without restriction of any 671 kind, provided that the above copyright notice and this paragraph are 672 included on all such copies and derivative works. However, this 673 document itself may not be modified in any way, such as by removing 674 the copyright notice or references to the Internet Society or other 675 Internet organizations, except as needed for the purpose of 676 developing Internet standards in which case the procedures for 677 copyrights defined in the Internet Standards process must be 678 followed, or as required to translate it into languages other than 679 English. 681 The limited permissions granted above are perpetual and will not be 682 revoked by the Internet Society or its successors or assigns. 684 This document and the information contained herein is provided on an 685 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 686 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 687 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 688 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 689 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.