idnits 2.17.1 draft-walker-ccamp-req-00.txt: -(316): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding 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: ---------------------------------------------------------------------------- == There are 9 instances of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 32 longer pages, the longest (page 14) being 61 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** 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. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- 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 (February 2001) is 8471 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) -- Missing reference section? '1' on line 17 looks like a reference -- Missing reference section? '7' on line 903 looks like a reference -- Missing reference section? '2' on line 164 looks like a reference -- Missing reference section? '3' on line 164 looks like a reference -- Missing reference section? '4' on line 227 looks like a reference -- Missing reference section? '5' on line 363 looks like a reference -- Missing reference section? '6' on line 450 looks like a reference Summary: 3 errors (**), 0 flaws (~~), 5 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force J. Jiang 3 Internet Draft D. Walker 4 Document: draft-walker-ccamp-req-00.txt J. Wang 5 Expires: August 2001 SS8 Networks Inc 6 February 2001 8 Common Control and Measurement Plane 9 Framework and Requirements 11 13 Status of this Memo 15 This document is an Internet-Draft and is in full conformance with 16 all provisions of Section 10 of RFC2026 [1]. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six 24 months and may be updated, replaced, or obsoleted by other documents 25 at any time. It is inappropriate to use Internet-Drafts as reference 26 material 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 Abstract 36 This document describes architectural and protocol requirements for 37 the Common Control and Measurement Plane. 39 Table of Contents 41 1. Introduction....................................................3 42 2. Definitions.....................................................4 43 3. Conventions used in this document...............................5 44 4. Common Control and Measurement Plane............................5 45 4.1. Functions of the Control and Measurement Plane................5 46 4.2. Centralized Architecture......................................6 47 4.3. Distributed Architecture......................................9 48 5. Architectural Requirements......................................9 49 5.1. Independence from Underlying Transport Networks...............9 50 5.2. Scalable to Very Large Networks..............................10 51 5.3. Flexibility..................................................10 53 Jiang/Walker/Wang 1 54 5.4. Steady State Operation.......................................10 55 5.5. Minimized Overhead...........................................11 56 5.6. Minimized Impact on Real-Time Performance....................11 57 5.7. Simplicity...................................................11 58 5.8. Survivability................................................11 59 5.9. Interoperability.............................................11 60 6. Proposed High Level Architecture...............................12 61 6.1. Architecture Overview........................................12 62 6.2. Single Protocol or Separate Protocols........................13 63 6.3. Reference Points.............................................14 64 7. TE Functional Requirements.....................................15 65 8. CE Functional Requirements.....................................16 66 8.1. Association Establishment and Management.....................16 67 8.2. Tunnel Management............................................16 68 8.3. Resource Management..........................................17 69 8.4. QoS policy capability........................................17 70 8.5. Service provisioning and control.............................18 71 8.6. OAM&P........................................................18 72 8.7. Robustness...................................................19 73 9. General Protocol Requirements..................................19 74 9.1. Transport Network Assumptions................................19 75 9.2. Association requirements.....................................19 76 9.3. Protocol performance requirements............................20 77 9.4. Transport Requirements.......................................20 78 9.5. Security requirements........................................21 79 9.6. Other Requirements...........................................21 80 10. Control Protocol Requirements.................................22 81 10.1. Resource requirements.......................................23 82 10.2. Tunnel Requirements.........................................23 83 10.3. Event Processing and Scripting..............................24 84 10.4. Policy Requirements.........................................25 85 10.5. Media transformation Requirements...........................25 86 10.6. Operation/management Requirements...........................25 87 10.7. Error Control...............................................26 88 10.8. Management Requirements.....................................26 89 11. Measurement Protocol Requirements.............................26 90 11.1. Topology and resource information...........................26 91 11.2. TE Capability Information...................................27 92 11.3. Status Information..........................................27 93 11.4. Tunnel Information..........................................28 94 11.5. Performance Information.....................................28 95 11.6. Statistics Information......................................28 96 11.7. Accounting Requirements.....................................28 97 11.8. Event Processing and Scripting..............................29 98 11.9. Operation/Management Requirements...........................29 99 11.10. Error Control..............................................29 100 12. Inter-CE Protocol Requirements................................30 101 12.1. Common requirements.........................................30 102 12.2. Internal capability.........................................30 103 12.3. External capability.........................................31 104 13. Security Considerations.......................................31 105 14. References....................................................31 106 15. Author's Addresses............................................32 108 Jiang/Walker/Wang 2 109 1. Introduction 111 As networking technology continues to evolve, there is an ever- 112 increasing number of transport layer protocols that one is likely to 113 encounter in developing end-to-end solutions. Along with the 114 growing stringency of Service Level Specifications (SLS), there is 115 both a need to be able to provide a finer level of control over 116 network traffic in terms of the level of service that can be 117 delivered by the various technologies, as well as a need to ensure 118 that the network is providing the required level of service. 120 The various network technologies, such as MPLS label switching, ATM, 121 Diffserv, optical switching, and more, frequently come with a unique 122 set of mechanisms that offer ISPs the tools they need to control and 123 monitor technology-specific or even vendor-specific islands. The 124 unique nature of these islands creates complex problems when larger 125 networks are created by interconnecting such islands. 127 This draft presents a framework and set of generic requirements that 128 are independent of the underlying technology and which can be used 129 to ensure that the network can be monitored and controlled to 130 provide specific levels of policy, security, and quality of service 131 characterics. 133 Networks can be functionally divided into three planes of activity: 134 a data or transport plane, a control plane, and a management plane. 136 The control plane consists of logical entities (Control Elements) 137 which perform network level coordination functions such as: state 138 information management (acquisition, representation, dissemination), 139 decision making (e.g. path selection), and action invocation (e.g. 140 signalling). 142 The transport plane provides consists of entities (such as layer 2 143 and layer 3 switches, routers, and others, collectively referred to 144 in this document as Transport Elements) which primarily switch or 145 forward data (bearer or signalling) traffic. These entities may be 146 statically or dynamically configured in order to determine how 147 particular traffic is to be treated. 149 The measurement plane provides transport level resource status 150 information to interested parties in order that appropriate policies 151 may be applied (e.g. allowing routers to determine the appropriate 152 next hop destination for outgoing packets). 154 The framework proposed in this draft suggests that Control Elements 155 are able to control and monitor one or more Transport Elements. 156 While the document presents a discussion on the relative merits of 157 centralized and distributed control networks, it should be 158 emphasized that CEs are logical entities which may or may not be co- 159 located with TEs in actual implementations. 161 Jiang/Walker/Wang 3 162 It must be noted that the requirements set out in this draft may be 163 partially satisfied by extending existing protocols, such as COPS 164 [7], MEGACO [2], OSPF [3], and others. 166 2. Definitions 168 Service domain: Service domain defines a portion of the network 169 under one service provider�s administration. All the network 170 elements within a service domain have consistent view of the network 171 and policy. 173 Clearing House (CH): Given the large number of access networks 174 belonging to different service domains, it is not possible to have 175 SLS between all domains on the Internet. A clearinghouse facilitates 176 the authorization and logging or accounting between service domains 177 for premium services. This does not preclude however some domains to 178 have direct bilateral agreements, so as not to use any clearinghouse 179 service when exchanging traffic. 181 Control and Measurement Plane: The control and measurement plane is 182 a functional layer which is built on top of transport network to 183 control the transport elements to perform service management, 184 traffic engineering, policy control, and QoS control functions. The 185 control and measurement plane is one of the three dimensions of a 186 service provider�s network, which includes transport plane (data 187 plane), control and measurement plane and management plane. 189 Control Element (CE): The network components providing control 190 capability for traffic engineering, service management, 191 protection/restoration, policy control and end-to-end QoS control. 192 These components communicate with TEs to collect network status and 193 resource information, compute source route or perform path 194 provisioning for tunnel management, execute policy logic, update its 195 policy information base, and exchange this information with other 196 CEs. 198 Transport Element (TE): The network components providing transport 199 function to switch or forward bearer traffic. Examples of TEs 200 include MPLS LSRs, ATM switches, Lambda switches, DiffServ capable 201 routers, PSTN-IP gateways, etc. A TE communicates with CE to report 202 network resource and status information, receive and execute policy 203 decisions from CE for traffic engineering, service management, 204 protection/restoration, policy control and end-to-end QoS control. 206 Peer: CEs are connected to each other via a logical link, or an 207 association. The two CEs that have associations form a peer 208 relationship. This peer relationship is abbreviated to as peer in 209 this draft. 211 Internal peer: An internal peer is a peer relationship between two 212 CEs in the same service domain. 214 Jiang/Walker/Wang 4 215 External peer: An external peer is a peer relationship between two 216 CEs in two different service domains. 218 Internal CE: An internal CE is a CE that has no external peer. 220 Border CE: A border CE is a CE that has at least one external peer. 222 3. Conventions used in this document 224 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 225 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 226 this document are to be interpreted as described in RFC-2119 [4]. 228 4. Common Control and Measurement Plane 230 A network can be functionally divided into three planes: a data or 231 transport plane, a control plane, and a management plane. The 232 control plane consists of network control elements. The network 233 control plane elements perform network level coordination functions 234 including: state information management (acquisition, 235 representation, dissemination), decision making (e.g., path 236 selection), and action invocation (e.g., signalling). In order to 237 manage state information of the network, measuring and monitoring 238 the network resource and status is the key function. To emphasize 239 this function, the control plane is referred to as control and 240 measurement plane in this draft. 242 4.1. Functions of the Control and Measurement Plane 244 This plane is designed to perform the following functions: 246 - Traffic engineering 248 It is able to control the traffic flows in the network so that the 249 network resource is utilized in a most efficient fashion. With 250 this feature, this plane must be able to handle various types of 251 traffic in terms of their QoS requirements including delay, packet 252 loss, bandwidth requirements, etc over a mixed underlying 253 transport networks. This feature requires the CEs to collect 254 traffic and resource information in the network, to compute the 255 best path for each flow, and to issue control commands to TEs. 256 This plane must support both time-dependent and state-dependent 257 traffic engineering. 259 - Support end-to-end QoS 261 This plane needs to support end-to-end QoS for its customers. For 262 this purpose, the CE must have not only the network resource 263 knowledge of its own service domain, but also access to the 264 performance measurements of the other service domains a particular 266 Jiang/Walker/Wang 5 267 flow is to transverse. These performance measurements are 268 collected by TEs and CEs in a service domain and may be exchanged 269 with CEs in other domains. 271 - Support policy 273 Various levels of policy need to be supported by this plane. These 274 include service policy, customer policy, resource policy, network 275 functional policy, and network element policy. This plane must 276 support policy creation, modification, and deletion. It must also 277 support service policy advertisement among service domains. It 278 must support three types of policy: QoS policy, service policy and 279 traffic engineering policy. The framework must be such that is 280 easily extended to support other policies. 282 - Support service provisioning and management 284 For a service provider, the traffic engineering and QoS control is 285 based on the customer�s service profile and its service policy. 286 The control plane must support customer service provisioning and 287 management. This include communication with Service Management 288 System (SMS) for Local Service Level Agreements (SLA) 289 specification, SLA negotiation, service creation, modification and 290 deletion. It should also be able to perform SLA advertisement 291 among the CEs within the same service domain and LSA exchange 292 among CEs in different service domains. It should also be able to 293 allocate service to specific customer flows as required by SMS. 295 In addition to the generic management function as described above, 296 this plane must also support management of particular services, such 297 as VPN service. 299 4.2. Centralized Architecture 301 The control and measurement plane can be deployed in two different 302 architectures: the control function is separate from the TEs or 303 control integrated with the TEs. The former is referred to as 304 centralized control and the latter is referred to as distributed 305 control. Neither model should necessarily rule out the other, so 306 that it is possible to have a centralized architecture with some CEs 307 just happening to be co-resident with TEs, and on the other hand it 308 is also possible to have a distributed architecture where the TE 309 function on some physical entities is null. 311 With centralized architecture, the control function is allocated in 312 one or a few centralized CEs that are physically separated from the 313 TEs. The interaction between the CE and the TEs is via a set of 314 protocols as defined and discussed in this draft. These protocols 315 must be independent of the underlying transport network. It is each 316 TE�s responsibility to translate its technology sub-network specific 317 resource representation into the abstracted common representation. 319 Jiang/Walker/Wang 6 320 All the CEs form a control network. The control network may consist 321 of one or more CEs depending on the size of the network and capacity 322 of the CE. In case of multiple CEs, a mechanism must be defined for 323 these CEs to communicate and synchronize policy, resource and 324 traffic information, and provisioned service. 326 The centralized architecture has the following advantages: 328 - Easier to benefit from management information continuously 329 collected by NMS (Network Management System) 331 This information, such as performance alarms, failure alarms, and 332 traps can be used with other information for the control elements 333 to make control decisions. 335 With distributed architecture, a distributed routing protocol 336 relies mainly on timers and missing PDUs to detect a failure 337 between two adjacent switching nodes. 339 - Easier for policy control 341 Policy control consists of policy creation, installation, 342 modification, deletion advertisement, and policy decision making. 343 In reality, policy is usually service provider based (service 344 policy, customer policy, accounting policy) or network based 345 (network function specific and network element policy). To be able 346 to provide end-to-end QoS, one service domain needs to exchange 347 service level policy with its neighboring domains. With a 348 centralized architecture, it is easier to maintain policy 349 consistency because the policy control is performed at one (or a 350 few) central place(s). 352 With distributed approach, the policy creation needs to be done 353 repeatedly on every transport elements. The policy advertisement 354 between different domains are even more difficult with distributed 355 architecture. 357 - Easier for traffic engineering of mixed underlying transport 358 network 360 A service provider�s network may consist of mixed types of sub- 361 networks. For example, a GMPLS network may consist of two Packet 362 Switched Capable (PSC) MPLS sub-networks connected by one Lambda 363 Switched Capable (LSC) MPLS sub-network [5]. With centralized 364 architecture, a centralized decision can be easily made based on 365 its consistent and complete view of the underlying network. 367 On the other hand, with distributed architecture, the routing 368 protocol are used to build and maintain a logical model of the 369 network. Because not all routing entities have the same view of 370 the overall network (e.g., two ATM label switching networks 371 connected with one lambda switching network, the ATM switch in an 372 MPLS-ATM network has different view from Lambda switch in an MPLS- 374 Jiang/Walker/Wang 7 375 optical network in terms of network topology, network resource and 376 congestion status), a best decision based on entire network is 377 difficult to make. 379 - Easier to operate 381 With centralized architecture, new features or policies can be 382 introduced with a simple upgrade. 384 With distributed architecture, upgrading every switch with new 385 routing software is difficult. 387 - Better flexibility 389 With centralized architecture, a set of protocols between CE and 390 TE must be well defined. This provides a flexibility where the 391 control and measurement function can be allocated. It also allows 392 separate TE and CE development to optimize their functionality. 394 - Better information consistency 396 With centralized architecture, information is stored in a few 397 central places. The possibility of session setup failure due to 398 inconsistent information is lower than that in distributed 399 architecture. 401 - Offload LSRs 403 With centralized architecture, the separate control and 404 measurement plane takes care of all the control and measurement 405 tasks. LSRs can concentrate on real time traffic switching. 407 With distributed architecture, some non-real-time tasks (topology 408 synchronization, policy advertisement, etc.) must also be executed 409 at TEs and compete with real time tasks for CPU time. 411 - Easier for end-to-end QoS control 413 For end-to-end QoS control, a decision maker needs to have 414 knowledge not only the traffic and resource in its own network, 415 but also those in other domains. It introduces a lot of overhead 416 to make the information available to every switch rather than to 417 only a few central control elements. 419 - Easier to extend for control of other networks 421 In the future, when new types of networks are included into 422 service provider�s network, it is easier to accommodate them into 423 a centralized control and measurement plane because the this plane 424 is an abstract and common plane and all the transport technology 425 specific function is kept by each TE. 427 Jiang/Walker/Wang 8 428 4.3. Distributed Architecture 430 In a distributed architecture, each TE communicates with other TEs 431 to collect network topology, resource, and traffic information and 432 performs route computation by itself. Each switch maintains the 433 policy and service profile for all its customers. The advantage of 434 distributed architecture over centralized one are as follows: 436 - Better survivability 438 With distributed architecture, if one TE fails, only the traffic 439 handled by this LSR is affected. The rest of the network will 440 continue to work. 442 On the other hand, with centralized architecture, if a CE fails, 443 all the services on the switches under the control of that CE will 444 be impacted. 446 - Easier to make use of existing routing protocols 448 Distributed IP routing (OSPF, IS-IS) has been deployed on TEs; 449 suggestions have been made to extend these protocols to support 450 traffic engineering and QoS [6]. These are fully distributed 451 protocols. 453 - Complex overall architecture 455 With centralized architecture, because the number of network 456 elements that can be managed by one control element is limited by 457 its capacity, multiple control elements may need to be deployed in 458 parallel. Then another centralized component on top of the control 459 elements must be deployed to take care of end-to-end on-demand 460 services. That makes the overall architecture complicated. With 461 distributed architecture, each transport element takes care of its 462 own for all the control capability. No complicated hierarchy is 463 involved. 465 - Better session setup latency 467 With a distributed approach, a tunnel setup message does not have 468 to go CE so the session setup latency is reduced. The same 469 reasoning applies for protection/restoration. 471 5. Architectural Requirements 473 The objective is to build a common plane for various underlying 474 transport networks. This plane has a common interface to the 475 underlying transport elements. The high level architectural 476 requirements are described below. 478 5.1. Independence from Underlying Transport Networks 480 Jiang/Walker/Wang 9 481 The underlying transport network can be based on any type of 482 transport technology. The interface between control elements and 483 transport elements must be generic. It must be suitable for any type 484 of networks. The parameters passed at the interface must be abstract 485 and suitable for carrying topology, resource, traffic, and policy 486 decision information for any type of networks. It is up to the 487 transport element to map its technology specific presentation of 488 above to the standard interface. 490 The architecture must be extensible to support more functions and 491 other network transport elements. 493 5.2. Scalable to Very Large Networks 495 Contemporary public networks are growing very fast with respect to 496 network size and traffic volume. The architecture must be designed 497 to work with small network consisting a few tens of TEs to a big 498 network consisting of a few thousands TEs. 500 5.3. Flexibility 502 With different transport networks, and at different stages of 503 deployment of the architecture, there may be different solutions to 504 the same issue. The architecture must be flexible in adopting 505 different mechanisms. 507 For example, the measurement results can be obtained in different 508 ways: using the measurement protocol as discussed in this draft, 509 using OSPF-TE when it is widely deployed in the network, or using 510 MIBs uploading. The architecture must be flexible to allow different 511 mechanisms to be easily plugged in. 513 In another example, a particular MPLS subnet may have its own built- 514 in traffic engineering mechanism. The architecture must allow the 515 transport elements to choose which mechanism (at control element or 516 of its own) to use. 518 In another scenario, a third party policy engine is already deployed 519 in the service provider�s network, this architecture must allow the 520 policy engine to be plugged into the control plane. 522 Another example is that at the early deployment stage, some network 523 parameters (e.g., CE to TE association) may be statically 524 provisioned and at advanced stage they may be obtained by protocol 525 (e.g., auto-discovery). As for provisioning, the plane should also 526 provide sufficient configuration options so that a network 527 administrator can tailor the system to a particular environment. 529 5.4. Steady State Operation 531 Jiang/Walker/Wang 10 532 The architecture must be such that the entire control system can 533 reach steady state fast. For example, this requires the routing 534 computation be relatively independent of dynamically changeable 535 parameters. 537 5.5. Minimized Overhead 539 This architecture should not introduce significant transport and 540 processing overhead. For this purpose, the control protocols should 541 be as simple as possible. The amount of information should be 542 minimized and the format to represent the information should be 543 efficient. 545 5.6. Minimized Impact on Real-Time Performance 547 With more functionality introduced into the control plane, session 548 setup latency will be degraded. The architecture must be designed so 549 that this impact is minimized. 551 5.7. Simplicity 553 The system should be as simple as possible, consistent with the 554 intended applications. The system should be relatively easy to use 555 (i.e., clean, convenient, and intuitive user interfaces). 557 Simplicity in user interface does not necessarily imply that the TE 558 system will use naive algorithms. Even when complex algorithms and 559 internal structures are used, such complexities should be hidden as 560 much as possible from the network administrator through the user 561 interface. 563 5.8. Survivability 565 It is critical for an operational network to recover promptly from 566 network failures and to maintain the required QoS for existing 567 services. Survivability generally mandates introducing redundancy 568 into the architecture, design, and operation of networks. 570 Survivability can be addressed at the device level by developing 571 network elements that are more reliable; and at the network level by 572 incorporating redundancy into the architecture, design, and 573 operation of networks. This draft requires that a philosophy of 574 robustness and survivability should be adopted in the architecture, 575 design, and operation of control and measurement plane. 577 5.9. Interoperability 579 Jiang/Walker/Wang 11 580 Whenever feasible, control and measurement systems and their 581 components should be developed with open standards based interfaces 582 to allow interoperation with other systems and components. 584 6. Proposed High Level Architecture 586 Based on the functions described in Sections 4 and 5, the proposed 587 architecture for the control plane is described in this section. 589 6.1. Architecture Overview 591 As illustrated in Figure 1, the control and measurement plane is 592 separated from and built on top of the transport network. The entire 593 controlled network is divided into service domains. One domain is 594 under management of a single service provider and the network 595 elements within one domain share consistent network view and policy 596 view. The entire controlled service domain consists of one or more 597 CEs and multiple TEs. Each TE is under the control of one CE. One CE 598 can control multiple TEs. 600 +------------------+ 601 | Clearing | 602 | House | 603 +------------------+ 604 A A 605 | | 606 |(R5) |(R5) 607 +-----------------------------------|----+ +----|-------------+ 608 | | | | | | 609 | V | | V | 610 | +-------------+ +-------------+ | | +-------------+ | 611 | | Control |<---->| Control |<------->| Control | | 612 | | Element | (R3) | Element | |(R4)| | Element | | 613 | +-------------+ +-------------+ | | +-------------+ | 614 | A A A A | | A A | 615 | | | | | | | | | | 616 | (R1)| |(R2) (R1)| |(R2) | | (R1)| |(R2) | 617 | | | | | | | | | | 618 | V V V V | | V V | 619 | +-------------+ +-------------+ | | +-------------+ | 620 | | Transport | | Transport | | | | Transport | | 621 ....| Element |......| Element |.........| Element |.... 622 | +-------------+ +-------------+ | | +-------------+ | 623 | | | | 624 | (domain 1) | | (domain 2) | 625 +----------------------------------------+ +------------------+ 627 Figure 1: CCAMP Architecture & Reference Points 629 Jiang/Walker/Wang 12 630 If there is more than one CE in the network, the CEs are connected 631 via associations in either a partial or full mesh. The CEs and their 632 associations together form a CE network. The links between CEs are 633 logical links, or associations. These CEs and their associations are 634 provisioned so that reachability (directly or indirectly) exists 635 between any pair of CEs. 637 In case of multiple CEs, each CE is responsible for managing a 638 number of TEs. Any TE is controlled by only one CE at any time. One 639 TE may have associations with more than one controller for 640 protection purpose. 642 Each TE communicates with its CE using two protocols: a control 643 protocol and a measurement protocol. The control protocol is used 644 for the CE to send policy decisions, tunnel setup information (e.g., 645 source routing path), and traffic filters for mapping incoming 646 traffic to the tunnel to be setup. The measurement protocol is used 647 for TEs to report network status and resource information to the CE. 649 Because multiple CEs may be deployed in one service domain, these 650 CEs need to communicate to each other so that they have the 651 consistent view about the service profiles of customers, policies, 652 network resource and status. For this purpose, these CEs need to 653 speak another protocol with its peers: inter-CE protocol. 655 The inter-CE protocol consists of two parts: intra-domain part and 656 inter-domain part. For the intra-domain part, the protocol allows 657 the CEs to share all policy and network information with each other. 658 No security check or policy filtering logic is required. While for 659 the inter-domain part, only the customer level policy and service 660 capability is exchanged. Security mechanisms must be applied to 661 inter-domain communication. Only the border CE needs to support both 662 intra-domain part and inter-domain part. The internal CEs only need 663 to support inter-domain part. 665 In this architecture, we propose direct communication between CEs 666 for inter-domain communication. Another alternative is to exchange 667 policy information between service domains via a Clearing House. 668 This alternative, however, is not addressed in this draft. 670 6.2. Single Protocol or Separate Protocols 672 From a functional point of view, the system requires two protocols, 673 control protocol and measurement protocol. These two protocols can 674 be kept separate or combined together. 676 With a single protocol, only one association needs to be established 677 and maintained between each TE and its CE. The messages exchanged 678 can be reduced because some information of two protocols can be 679 carried in a single message. This reduces the protocol overhead. 681 Jiang/Walker/Wang 13 682 With separate protocols, it is easy to develop each protocol 683 independently and to incorporate other protocols into the 684 architecture. For example, when TE-OSPF is widely deployed, it can 685 be used for measurement and reporting purpose, and therefore no new 686 measurement protocol is needed. 688 Although more investigation is required before reaching an agreement 689 on single protocol or separate protocol, in this draft, we describe 690 the requirements separately. 692 6.3. Reference Points 694 In this architecture illustrated in Figure 1, the following 695 reference points are defined. 697 - Reference Point R1 699 Policy control information flow between CE and TE is captured in 700 R1. The information across this point communicates policy-based 701 session setup request and decision, traffic filter decision, and 702 policy installation request between CE and TE. This protocol is a 703 client-server protocol with the TE as client and the CE as the 704 server. 706 - Reference Point R2 708 Transport Elements uploading information and/or measurement 709 information flow between CE and TE is captured in this reference 710 point. The information across this reference point communicates TE 711 topology, resource, network status and measurement information. 712 The protocol used at this interface is client-server protocol with 713 TE as client and CE as server. 715 - Reference Point R3 717 Information flowing between two internal CEs is captured in this 718 point. The information across this reference point communicates 719 network topology, resource, and status information of the portion 720 of the network and TEs under its control. It also communicates 721 policy information and service capability information learned from 722 other domains. The protocol used at this point is a peer protocol. 724 - Reference Point R4 726 Information flowing between two border CEs in different domains is 727 captured in this point. The information across this reference 728 point communicates pricing, authorization, usage, policy, and 729 service capability information. The policy information flowing at 730 this point includes customer specific policy, service specific 731 policy, and resource policy. It is used for advertising, 732 negotiating and notifying policy information. The policy 733 information across this point can be either both globally 735 Jiang/Walker/Wang 14 736 available policy information and peer domain specific policy 737 information (if clearing house is not available) or only peer 738 domain specific policy (if clearing house is used for global 739 available policy information). This protocol is a peer protocol. 741 - Reference Point R5 743 The information flowing between CE and Clearinghouse is captured 744 in this reference point. The information flowing across this 745 reference point is inter-domain pricing, authorization, and usage 746 information as well as customer, service, and resource specific 747 policy. The protocol used at this point is client-server protocol 748 with CE as client and CH as server. 750 7. TE Functional Requirements 752 The underlying network could be MPLS network, ATM network, optical 753 switching network, etc. or any combination of the above. However, 754 the following assumptions are made about the network and the TE: 756 - The TEs are connected to each other in a arbitrary topology 757 (meshed, star, tree, etc) 759 - One TE can have different types of interfaces: different MPLS 760 capable interfaces, or non-MPLS interfaces. 762 - Every MPLS capable interface has IP address, implemented IP stack, 763 running IP routing, running MPLS signaling (e.g., LDP and CR-LDP) 765 - TEs that have both MPLS and non-MPLS interfaces are able to do 766 traffic mapping between non-MPLS traffic (packets, time slots, 767 lambdas, physical interfaces) and MPLS traffic according to a 768 traffic classifier 770 - TEs that have different types of MPLS interface are able to map 771 between those interfaces 773 - Every TE is able to perform resource reservation and release 775 - Every TE is able to collect network topology and status 776 information and report it to CE 778 - Every TE is able to perform performance measurement and report the 779 results to CE. 781 - Every TE is able to collect and report network resource usage 782 information and report it to CE 784 - Every TE supports the control protocol and measurement protocol as 785 described in this draft, including establishing and maintaining 786 association with CE, generating, receiving, and processing 788 Jiang/Walker/Wang 15 789 protocol messages, switchover to a backup CE in case that the 790 primary CE failure is detected, etc. 792 - Every TE must support either provisioned CE assignment or CE auto- 793 discovery. 795 - Every TE is able to enforce policy decision it received from CE 797 8. CE Functional Requirements 799 The CE is the core component of this architecture. It must provide 800 the following capabilities. 802 8.1. Association Establishment and Management 804 These requirements for a CE to establish and maintain associations 805 with TEs and its CE peers are addressed by each protocol in 806 seubsequent sections. For the purpose of completion, they are also 807 listed here. 809 - It is able to establish and maintain association with its intra- 810 domain peers and inter-domain peers 812 - It is able to monitor whether its peers are alive 814 - It is able to delete the association with a peer when the peer 815 fails or the peer relationship is removed by operator 817 - It must support auto-discovery of CE by TE 819 - When a new TE added into the network, the CE is able to coordinate 820 with other CEs to decide which CE is to control the new TE. 822 - It is able to establish and maintain associations with the TEs 823 under its control 825 - It is able to reassign a TE under its control to another CE and 826 communicate this reassignment with TE and CE. 828 - It is able to detect its peer�s failure or its TE�s failure and 829 close the association 831 8.2. Tunnel Management 833 - Tunnel routing involves the selection of a path from the 834 originating node to the destination node in a network. CE should 835 support time-dependent routing and state-dependent routing. 837 - The architecture also allows other routing engine or routing 838 mechanisms to be plugged in. In this case, the CE must also be 840 Jiang/Walker/Wang 16 841 able to decide which routing mechanism to be used for a particular 842 tunnel setup request according to its local policy. 844 - It is able to compute and setup a path according to the traffic 845 and QoS requirements. 847 - It is able to manage routing table from different route mechanisms 848 and perform route lookup based on its local policy. 850 - It is able to instruct TEs to establish tunnels according to the 851 path it specified 853 - It is able to maintain all the information related to each tunnel 854 originating from the controlled TE. The tunnel could be any type 855 of point-to-point, point-to-multipoint or multipoint-to-point. 857 - It is able to instruct TEs to modify an established tunnel without 858 affecting existing traffic 860 - It is able to delete a tunnel upon request or due to network 861 failure 863 8.3. Resource Management 865 - It is able to store the network topology and resource formation in 866 a way that it is easy to be advertised and easy to be used for 867 route computation 869 - It must maintain the network resources information for any type of 870 interfaces 872 - It is able to perform admission control upon a request for tunnel 873 establishment based on resource availability, setup requirements 874 and its local policy 876 - It must be able to update the resource utilization of the 877 underlying network upon tunnel setup or release 879 - It must be able to update its resource utilization information 880 upon report from TE or other CEs 882 - It must be able to advertise any topology change reported by TEs 883 under its control to other CEs within the same domain 885 - It must be able to advertise any resource utilization change 886 calculated by itself or reported by TEs to other CEs within the 887 same domain 889 8.4. QoS policy capability 891 Jiang/Walker/Wang 17 892 - It must be able to make Policy Decision upon the request from TE, 893 other network components such as SIP proxy server, or provision 895 - It must support QoS policy management. It is able to create and 896 maintain a policy database in a format that is easy to update and 897 easy to apply. 899 - It must be able to communicate with a separate policy repository 900 using a standard protocol 902 - It must support both policy provisioning and policy outsourcing 903 modes as defined in COPS [7]. For provisioning mode, it is able to 904 install polices to the TEs that are under its control. 906 - It must support policy management so that the service provider is 907 able to create, modify or delete policy via a standard user 908 interface (CLI, GUI). 910 - It must be able to distribute new policy items to its intra-domain 911 peers. The new policy could be created by an operator, or learned 912 from its neighbor domain peers. 914 - It must be able to advertise its policy to other service domains 915 according to its filtering policy. 917 - It must be able to negotiate the service, pricing, and customer 918 policy with other service domains. 920 - It must support various types of policies. 922 - The policy framework must be extensible to include other policy in 923 addition to QoS policy 925 8.5. Service provisioning and control 927 - It must be able to interact with Service Management System (SMS) 928 to create, modify, and delete services 930 - It must be able to interact with SMS to provision services 932 - It must able to provision services based on Service Level 933 Specification (SLS) with its access customers 935 - It must be able to provision services based on Service Level 936 Agreement (SLA) with its peer service providers 938 - It should be able to exchange SLA with other service domains 940 8.6. OAM&P 942 A CE must be able to perform the following standard OAMP functions: 944 Jiang/Walker/Wang 18 945 - Operation management: load/boot, software/hardware upgrade, 946 capability to enable or disable resource and/or features. 948 - Configuration management: provisioning and configuring components 949 and applications 951 - Performance management: performance monitoring, data collecting 952 and analysis 954 - Accounting management: gathering statistics and usage information 955 for accounting or billing purposes 957 - Fault management: problems/symptoms report and handling 959 8.7. Robustness 961 The control architecture must provide three level protections: 963 - Network level protection: When one CE fails, other CEs will 964 automatically take care of all the TEs under failed CE�s control. 966 - Link level protection: Physical or logical link failure should not 967 cause the association termination. 969 9. General Protocol Requirements 971 In the control architecture described in Section 6, three protocols 972 have been defined. They are control protocol, measurement protocol, 973 and inter-CE protocol. The inter-CE protocol is divided into two 974 portions: intra-domain part and inter-domain part. This section 975 discusses general protocol requirements that apply to all three 976 protocols. 978 9.1. Transport Network Assumptions 980 The protocols must assume that the underlying network: 982 - May be over large shared networks. 984 - Assures reliable delivery of messages. 986 - Does not guarantee message delivery delay. 988 - Does not guarantee ordering of messages: sequenced delivery of 989 messages associated with the same source of events is not assumed. 991 9.2. Association requirements 993 Jiang/Walker/Wang 19 994 For any of the three protocols to function, an association must be 995 established between two parties. The following are association 996 related requirements. 998 Each protocol must 1000 - be able to establish, maintain and terminate association between 1001 two communication parties (between CE and TE or between two CEs) 1003 - allow the association to be specified by provisioning 1005 - allow the association between CE and TE to be established by auto- 1006 discovery 1008 Each TE is able to discover and registered with CE automatically. 1009 CEs should be able to decide which CE should control the 1010 discovered TE. 1012 - provide a method for the TE to inform a CE that the it received a 1013 command that is under the control of a different CE 1015 - support a method for the TE to inform a CE that it cannot handle 1016 any more requests 1018 - allow a CE to terminate an association and redirect a TE to 1019 another CE 1021 9.3. Protocol performance requirements 1023 Each of the three protocols: 1025 - should minimize message exchanges between TE and CE and between 1026 CEs 1028 - should make efficient use of the underlying transport mechanism 1030 For example, protocol PDU sizes vs. transport MTU sizes needs to 1031 be considered in designing the protocols. 1033 - must not contain inherent architectural or signaling constraints 1034 that would limit peak throughput rates or the number of TEs a CE 1035 can control 1037 - should allow for default/provisioned settings so that commands 1038 need only contain non-default parameters 1040 9.4. Transport Requirements 1042 Each of the three protocols: 1044 Jiang/Walker/Wang 20 1045 - must provide the ability to abort delivery of obsolete messages at 1046 the sending end if their transmission has not been successfully 1047 completed 1049 For example, aborting a command that has been overtaken by events. 1051 - should support priority messages 1053 The protocol should allow a command precedence to allow priority 1054 messages to supercede non-priority messages. 1056 - should support large fan-out at the CE 1058 - must provide a way for one entity to correlate commands and 1059 responses with the other entity 1061 - must provide a reason for any command failure 1063 - must assure that loss of a packet not stall messages not related 1064 to the message(s) contained in the packet lost 1066 9.5. Security requirements 1068 Security mechanisms may be specified as provided in underlying 1069 transport mechanisms, such as IPSEC. The protocol, or such 1070 mechanisms, must: 1072 - allow for mutual authentication at the start of a CE-TE 1073 association, especially for inter-domain associations 1075 - allow for preservation of the control messages once the 1076 association has been established 1078 - allow for optional confidentiality protection of control messages 1080 - allow a choice in the algorithm to be used 1082 - across untrusted domains in a secure fashion 1084 - define mechanisms to mitigate denial of service attacks 1086 In addition, it may be desirable for the protocol to be able to pass 1087 through commonly used firewalls. 1089 9.6. Other Requirements 1091 Each of the three protocols must: 1093 - support multiple operations to be invoked in one message and 1094 treated as a single transaction 1096 Jiang/Walker/Wang 21 1097 - be both modular and extensible 1099 Not all implementations may wish to support all of the possible 1100 extensions for the protocol. This will permit lightweight 1101 implementations for specialized tasks where processing resources 1102 are constrained. This could be accomplished by defining particular 1103 profiles for particular uses of the protocol. 1105 - be flexible in allocation of intelligence between CE and TE 1107 For example, an CE may want to allow the TE to assign particular 1108 TE resources in some implementations, while in others, the CE may 1109 want to be the one to assign TE resources for use. In another 1110 example, CE may allow TE to do path computation in some 1111 implementations, while in others, the CE does the path computation 1112 by itself and the TE must take that path. 1114 - support scalability from very small to very large TEs 1116 The protocol must support TEs with capacity ranging from one to 1117 millions of connections. 1119 - support scalability from very small to very large CE span of 1120 control (i.e. The protocol should allow CEs to control from one to 1121 a few thousands of TEs) 1123 - support the needs of an edge TE that supports small number of 1124 tunnels, and the needs of large TEs supporting tens of thousands 1125 of tunnels 1127 Protocol mechanisms favoring one extreme or the other should be 1128 minimized in favor of more general-purpose mechanism applicable to 1129 a wide range of TEs. Where special purpose mechanisms are proposed 1130 to optimize a subset of implementations, such mechanisms should be 1131 defined as optional, and should have minimal impact on the rest of 1132 the protocol. 1134 - facilitate TE and CE version upgrades independently of one another 1135 (the protocol must include a version identifier in the initial 1136 message exchange) 1138 - facilitate the discovery of the protocol capabilities of the one 1139 entity to the other 1141 - specify commands as optional (can be ignored) or mandatory (must 1142 be accepted or rejected) 1144 - within a command, specify parameters as optional (can be ignored) 1145 or mandatory (must be accepted or rejected). 1147 10. Control Protocol Requirements 1149 Jiang/Walker/Wang 22 1150 The control protocol is running between CE and controlled TEs. In 1151 addition to the general protocol requirements listed in Section 9, 1152 this protocol must meet the following requirements. 1154 10.1. Resource requirements 1156 The control protocol must 1158 - support resource allocation for use by a particular tunnel and 1159 support its subsequent release at various granularities 1161 - allow modification of resource reservation without affecting 1162 existing services 1164 - allow release in a single exchange of messages, of all resources 1165 associated with a particular set of connectivity and/or 1166 association between a given number of terminations 1168 - not require the TE to maintain a sense of future time: a resource 1169 allocation/reservation remains in effect until explicitly released 1170 by the CE 1172 - provide a method for the CE to request that the TE to release all 1173 resources currently in use, or reserved, for any or all tunnels 1175 - provide a way for the TE to indicate that it was unable to perform 1176 a requested action because of resource exhaustion, or because of 1177 temporary resource unavailability 1179 10.2. Tunnel Requirements 1181 The control protocol must: 1183 - support establishment, modification and deletion of connections 1184 involving any types of layer 1 and layer 2 networks and any 1185 combinations 1187 - support establishment, modification and deletion of tunnels 1188 involving any amount of resource reservation 1190 - support unidirectional, symmetric bi-directional, and asymmetric 1191 bi-directional tunnels 1193 - support point-to-point, point-to-multiple, and multiple-to-point 1194 tunnels 1196 - allow TE to request CE for a tunnel setup (including admission 1197 control, policy control, path computation, etc.) 1199 - allow CE to specify the entire path or partial path for a tunnel 1201 Jiang/Walker/Wang 23 1202 - allow the specification of traffic filter (classifier) for the 1203 tunnel with the granularity of the traffic filter as following: 1205 PQ (Port Quadruples): same IP source address prefix, destination 1206 address prefix, TTL, IP, protocol and TCP/UDP source/destination 1207 ports 1209 PQT (Port Quadruples with TOS): same IP source address prefix, 1210 destination address prefix, TTL, IP, protocol and TCP/UDP 1211 source/destination ports, and same IP header TOS field (including 1212 precedence and TOS bits) 1214 HP (Host Pair): same specific IP source and destination addresses 1216 HPT (Host Pair with TOS): same specific IP source and destination 1217 addresses with same IP header ToS field 1219 NP (Network Pair): same IP source and destination address prefix 1220 (variable length) 1222 DN (Destination Network): same IP destination network address 1223 prefix (variable length) 1225 ER (Egress Router): same egress router ID 1227 NAS (Next-hop AS): same next-hop AS number 1229 DAS (Destination AS): same destination AS number 1231 SST (Source Specific Tree): same source address and multicast 1232 group 1234 SMT (shared multicast Tree): same multicast group address 1236 Same source and destination IP address with same DiffServ PHB 1238 Same source and destination IP address with same RSVP flow ID 1240 - allow dynamic modification of traffic filter to add or remove any 1241 flows to/from the tunnel without affecting existing service 1243 - support rerouting of an existing tunnel to a different path 1245 - allow CE to specify the priority of the tunnel 1247 - allow the TE to report events such as resource reservation and 1248 tunnel setup completion 1250 10.3. Event Processing and Scripting 1252 The control protocol must allow CE to enable/disable monitoring for 1253 specific supervision events 1255 Jiang/Walker/Wang 24 1256 10.4. Policy Requirements 1258 The control protocol must: 1260 - allow TE to communicate policy request (usually together with 1261 tunnel setup request) to CE 1263 - allow CE to communicate policy decision information to TE (usually 1264 together with explicit path information for the tunnel) 1266 - allow CE to install policy to TE 1268 - allow CE to modify the installed policy at TE 1270 10.5. Media transformation Requirements 1272 The control protocol must allow CE to instruct TE about 1273 mediation/adaptation (or traffic mapping) of flows between different 1274 types of transport interfaces. 1276 10.6. Operation/management Requirements 1278 The control protocol must: 1280 - support detection and recovery from loss of contact due to 1281 failure/congestion of communication links or due to CE or TE 1282 failure 1284 - support detection and recovery from loss of synchronized view of 1285 resource and tunnel states between CE and TEs (e.g. through the 1286 use of audits) 1288 - provide a means for CE and TE to provide each other with booting 1289 and reboot indications, and what the TE's configuration is 1291 - permit more than one backup CE and provide an orderly way for the 1292 TE to contact one of its backup CEs 1294 - provide for an orderly switch back to the primary CE after it 1295 recovers 1297 - provide a mechanism so that when a CE fails, tunnels already 1298 established can be maintained 1300 The protocol does not have to provide a capability to maintain 1301 tunnels in the process of being connected, but not actually 1302 connected when the failure occurs. 1304 Jiang/Walker/Wang 25 1305 10.7. Error Control 1307 The control protocol must: 1309 - allow for the TE to report reasons for abnormal failure of lower 1310 layer tunnels 1312 - allow the TE to notify the CE that an interface was terminated and 1313 communicate a reason when an interface is taken out-of-service 1314 unilaterally by the TE due to abnormal events. 1316 - allow the CE to acknowledge that some resource has been taken out- 1317 of-service. 1319 - allow the TE to request the CE to release some resource and 1320 communicate a reason. 1322 - allow the CE to specify its decision to take resource down, leave 1323 it as is or modify it. 1325 10.8. Management Requirements 1327 The control protocol must: 1329 - provide information on: 1331 . mapping between resources and supporting physical entities 1333 . statistics on quality of service on the control and signaling 1334 interfaces 1336 . statistics required for traffic engineering within the TE 1338 - allow the TE to provide to the CE all information the CE needs to 1339 provide in its MIB 1341 - allow the TE to provide the number of policy query, execution, and 1342 advertisements 1344 11. Measurement Protocol Requirements 1346 The measurement protocol also runs between CE and TEs. In addition 1347 to the general protocol requirements listed in Section 9, this 1348 protocol must meet the following requirements. 1350 11.1. Topology and resource information 1352 The following information must be reported to the CE immediately 1353 after a CE-TE association is established, whenever a network 1355 Jiang/Walker/Wang 26 1356 topology changed (node or link added into or removed from the 1357 network), and upon the request from CE: 1359 - TE must report underlying network topology information. Each TE is 1360 only responsible for reporting its own interfaces. 1362 - For each interface TE reports interface type (e.g., pure IP, RSVP, 1363 DiffServ, PSC, TDM, LSC, or FSC), local and remote IP addresses, 1364 and total network resource allocated to be used by this Control 1365 System in both directions. 1367 - For each interface, TE reports bandwidth reservation granularity 1368 (e.g., number of bytes, slot rate, lambda capacity). 1370 - For each interface, TE reports performance parameters including 1371 propagation delay and packet loss rate. 1373 The following information must be reported upon request from CE or 1374 whenever a pre-specified network resource threshold is crossed due 1375 to establishment of new tunnels or release or modification of an 1376 existing tunnels: 1378 - For a successfully established tunnel, the originating TE reports 1379 the committed resource reservation. 1381 - For tunnel release not triggered by CE, TE reports resource 1382 release by indicating to CE the tunnel ID of the tunnel that has 1383 been released. 1385 11.2. TE Capability Information 1387 The protocol must allow TE to indicate to CE its capabilities as 1388 listed below. 1390 - Whether it is an internal TE or border TE 1392 - Whether it is able to perform tunnel merge 1394 - What kinds of traffic mapping it supports 1396 - Whether it is able to setup uni-directional, synchronous bi- 1397 directional, or asynchronous bi-directional tunnels 1399 11.3. Status Information 1401 The measurement protocol must allow the CE to request and the TE to 1402 report the following: 1403 - status and all information about the interface when a new 1404 interface is added or activated. 1406 - link failure or deactivation 1408 Jiang/Walker/Wang 27 1409 - congestion status in the network 1411 11.4. Tunnel Information 1413 In most cases, CE will keep all the tunnel related information. 1414 There may be cases CE needs to request that information from the TE. 1415 The protocol must allow: 1417 - CE to request and TE to report tunnel related information (source 1418 and destination IP address, traffic filter, merge point, etc.) 1420 - CE to request and TE to report all tunnels associated with a 1421 particular interface. 1423 11.5. Performance Information 1425 The protocol must allow the CE to request and TE to report 1426 performance information such as round-trip delay, packet loss rate, 1427 etc. for a particular tunnel or a particular interface. 1429 11.6. Statistics Information 1431 In most cases, the CE keeps all the statistics information for all 1432 the TEs under its control. However, there may be cases that CE needs 1433 to request the information from each a particular TE. So the 1434 protocol must allow the CE to request and TE to report the following 1435 statistics information: 1437 - the number of tunnels that meet certain requirements (on the node, 1438 on a particular interface, to a particular IP address, duration 1439 exceeding 10 min, etc.) 1441 - the duration of a particular tunnel 1443 - the whole profile of a particular tunnel 1445 11.7. Accounting Requirements 1447 The measurement protocol must: 1449 - support a common identifier to mark resources related to one 1450 tunnel 1452 - support collection of specified accounting information from TEs 1454 - provide the mechanism for the CE to specify that the TE report 1455 accounting information automatically at end of a session, in mid- 1457 Jiang/Walker/Wang 28 1458 session upon request, at specific time intervals as specified by 1459 the TEs and at unit usage thresholds as specified by the CE 1461 - specifically support collection of: 1463 . Start and stop time, by media flow 1465 . Volume of content carried (e.g. number of packets/cells 1466 transmitted, number received with and without error, inter- 1467 arrival jitter), by media flow 1469 - allow the CE to have some control over which statistics are 1470 reported, to enable it to manage the amount of information 1471 transferred 1473 11.8. Event Processing and Scripting 1475 The measurement protocol must allow CE to enable/disable monitoring 1476 for specific supervision events. 1478 11.9. Operation/Management Requirements 1480 The measurement protocol must: 1482 - Support detection and recovery from loss of contact due to 1483 failure/congestion of communication links or due to CE or TE 1484 failure. 1486 - Support detection and recovery from loss of synchronized view of 1487 resource and connection states between CE and TEs (e.g. through 1488 the use of audits). 1490 - Provide a means for CE and TE to provide each other with booting 1491 and reboot indications, and what the TE's configuration is. 1493 - Permit more than one backup CE and provide an orderly way for the 1494 TE to contact one of its backups. 1496 - Provide for an orderly switch back to the primary CE after it 1497 recovers. 1499 - Provide a mechanism so that when a CE fails, tunnels already 1500 established can be maintained. The protocol does not have to 1501 provide a capability to maintain tunnels in the process of being 1502 connected, but not actually connected when the failure occurs. 1504 11.10. Error Control 1506 The measurement protocol must 1508 Jiang/Walker/Wang 29 1509 - allow for the TE to report reasons for abnormal failure of lower 1510 layer tunnels 1512 - allow the TE to notify the CE that an interface was terminated and 1513 communicate a reason when an interface is taken out-of-service 1514 unilaterally by the TE due to abnormal events 1516 - allow the CE to acknowledge that some resource has been taken out- 1517 of-service 1519 12. Inter-CE Protocol Requirements 1521 This protocol consists of two portions: internal part and external 1522 portion. There are some common requirements that apply to both 1523 internal and external portion. Some other requirements are specific 1524 for internal portion or external portion. 1526 12.1. Common requirements 1528 The following requirements apply for both internal portion and 1529 external portion. Both inter-CE protocol must CEs, both in the same 1530 domain and in different domains, to: 1532 - support arbitrary network topology of Controllers (meshed, star, 1533 tree, etc.) 1535 - allow the Controller peer relationship be provisioned 1537 - support automatic peer discovery 1539 - support detection and recovery from loss of contact due to 1540 failure/congestion of communication links or due to Controller 1541 failure 1543 - support detection and recovery from loss of synchronized view of 1544 resource and connection states between Controllers 1546 - provide a mechanism so that when a Controller fails, connections 1547 already established can be maintained 1549 The protocol does not have to provide a capability to maintain 1550 connections in the process of being connected, but not actually 1551 connected when the failure occurs. 1553 12.2. Internal capability 1555 The following information is exchange between CEs so that all the 1556 CEs within a domain have a consistent view of the network. The 1557 inter-CE protocol must allow CEs in the same domain to: 1559 Jiang/Walker/Wang 30 1560 - exchange topology information 1562 - exchange network resource information 1564 - exchange network status information 1566 - exchange tunnel and its allocated resource information 1568 - advertise policy information within the service domain 1570 - negotiate the new assignment of TEs from one CE to another 1572 12.3. External capability 1574 The inter-CE protocol must allow CEs in different domains to: 1576 - exchange service level policy 1578 - exchange pricing and usage information 1580 - exchange performance measurements of their service domain 1582 - exchange Service Level Agreement (SLA) 1584 13. Security Considerations 1586 Security requirements for the protocols are listed in Section 10.5. 1588 14. References 1590 1 Bradner, S., "The Internet Standards Process -- Revision 3", BCP 1591 9, RFC 2026, October 1996. 1593 2 Cuervo, F., et al, "Megaco Protocol Version 1.0", RFC 3015, 1594 November 2000. 1596 3 Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998. 1598 4 Bradner, S., "Key words for use in RFCs to Indicate Requirement 1599 Levels", BCP 14, RFC 2119, March 1997. 1601 5 Ashwood-Smith, P., et al, "Generalized MPLS - Signaling 1602 Functional Description," Internet Draft, , work in progress. 1605 6 Katz, D., and Yeung, D., "Traffic Engineering Extensions to 1606 OSPF," Internet Draft, , 1607 work in progress. 1609 Jiang/Walker/Wang 31 1610 7 Durham, D., et al, "The COPS (Common Open Policy Service) 1611 Protocol", RFC 2748, January 2000. 1613 15. Author's Addresses 1615 Jianping Jiang 1616 SS8 Networks Inc. 1617 55 Commerce Valley Drive West 1618 Toronto, ON L3T 7B9 1619 Canada 1620 Phone: +1 905 889 5900 1621 Email: jainping@ss8.com 1623 Dave Walker 1624 SS8 Networks Inc. 1625 495 March Road 1626 Ottawa, ON K2K 3G1 1627 Canada 1628 Phone: +1 613 592 2100 1629 Email: drwalker@ss8.com 1631 Jianli Wang 1632 SS8 Networks Inc. 1633 495 March Road 1634 Ottawa, ON K2K 3G1 1635 Canada 1636 Phone: +1 613 592 2100 1637 Email: jianli@ss8.com 1639 Full Copyright Statement 1641 Copyright (C) The Internet Society (2001). All Rights Reserved. 1643 This document and translations of it may be copied and furnished to 1644 others, and derivative works that comment on or otherwise explain it 1645 or assist in its implementation may be prepared, copied, published 1646 and distributed, in whole or in part, without restriction of any 1647 kind, provided that the above copyright notice and this paragraph 1648 are included on all such copies and derivative works. However, this 1649 document itself may not be modified in any way, such as by removing 1650 the copyright notice or references to the Internet Society or other 1651 Internet organizations, except as needed for the purpose of 1652 developing Internet standards in which case the procedures for 1653 copyrights defined in the Internet Standards process must be 1654 followed, or as required to translate it into languages other than 1655 English. 1657 The limited permissions granted above are perpetual and will not be 1658 revoked by the Internet Society or its successors or assigns. 1660 Jiang/Walker/Wang 32 1661 This document and the information contained herein is provided on an 1662 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1663 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1664 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1665 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1666 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1668 Jiang/Walker/Wang 33