idnits 2.17.1 draft-dios-ccamp-control-models-customer-provider-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. 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.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 21, 2014) is 3566 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFC4397' is mentioned on line 183, but not defined == Missing Reference: 'G.807' is mentioned on line 233, but not defined == Missing Reference: 'G.8081' is mentioned on line 233, but not defined == Unused Reference: 'RFC2119' is defined on line 526, but no explicit reference was found in the text == Unused Reference: 'RFC3107' is defined on line 529, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3107 (Obsoleted by RFC 8277) Summary: 2 errors (**), 0 flaws (~~), 6 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group O. Gonzalez de Dios, Ed. 3 Internet-Draft Telefonica GCTO 4 Intended status: Informational J. Meuric, Ed. 5 Expires: January 22, 2015 Orange 6 D. Ceccarelli 7 Ericsson 8 July 21, 2014 10 Terminology and Models for Control of Traffic Engineered Networks with 11 Client-Server Relationship 12 draft-dios-ccamp-control-models-customer-provider-01 14 Abstract 16 Different kinds of relationships can be established among 17 interconnected Traffic Engineered Networks. In particular, this 18 document focuses on the case where there is a client-server relation 19 between the network domains. The domain interconnection is a policy 20 and administrative boundary. This informational document collects 21 current terminology and provides a taxonomy for the posible control 22 plane based operation models. 24 Each control model defines, on the one hand, the level of information 25 that the domain acting as client receives by control plane means from 26 the domain acting as server and, on the other hand, the control model 27 will determine what can be requested from the client domain to the 28 server domain. 30 Status of This Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at http://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on January 22, 2015. 47 Copyright Notice 49 Copyright (c) 2014 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (http://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the Simplified BSD License. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 65 1.1. Examples of Client-Server TE Network Domain Scenarios . . 3 66 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 67 2.1. Routing domain . . . . . . . . . . . . . . . . . . . . . 4 68 2.2. Overlay of routing domains . . . . . . . . . . . . . . . 4 69 2.3. Multilayer . . . . . . . . . . . . . . . . . . . . . . . 4 70 2.4. Policy . . . . . . . . . . . . . . . . . . . . . . . . . 5 71 2.5. Client Domain - Server Domain Interface . . . . . . . . . 5 72 2.5.1. UNI in IP over Optical Networks . . . . . . . . . . . 5 73 2.5.2. ITU-T Definition of UNI . . . . . . . . . . . . . . . 5 74 2.5.3. OIF Definition of UNI . . . . . . . . . . . . . . . . 6 75 2.5.4. Proposed Vocabulary . . . . . . . . . . . . . . . . . 6 76 2.6. Reachability . . . . . . . . . . . . . . . . . . . . . . 7 77 2.6.1. Unqualified Reachability . . . . . . . . . . . . . . 7 78 2.6.2. Qualified Reachability . . . . . . . . . . . . . . . 7 79 2.6.3. Qualified Reachability with associated potential TE 80 path . . . . . . . . . . . . . . . . . . . . . . . . 8 81 3. Control Models . . . . . . . . . . . . . . . . . . . . . . . 8 82 3.1. Signaling Only . . . . . . . . . . . . . . . . . . . . . 8 83 3.1.1. Signaling with Requirements . . . . . . . . . . . . . 9 84 3.1.2. Signaling with Collection . . . . . . . . . . . . . . 9 85 3.2. Signaling and Reachability Model . . . . . . . . . . . . 9 86 3.2.1. Signalling + Basic Reachability . . . . . . . . . . . 10 87 3.2.2. Signalling + Qualified Reachability . . . . . . . . . 10 88 3.2.3. Signalling + Qualified Reachability + Potential 89 Services . . . . . . . . . . . . . . . . . . . . . . 10 90 3.3. Service Atributes vs service constraints . . . . . . . . 10 91 3.4. Other Models . . . . . . . . . . . . . . . . . . . . . . 11 92 3.4.1. Multi-Layer Networks / Multi-Region Networks . . . . 11 93 3.4.2. Management Model . . . . . . . . . . . . . . . . . . 11 94 4. Abstraction . . . . . . . . . . . . . . . . . . . . . . . . . 11 95 5. Security Considerations . . . . . . . . . . . . . . . . . . . 11 96 6. Contributing Authors . . . . . . . . . . . . . . . . . . . . 11 97 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 98 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 99 8.1. Normative References . . . . . . . . . . . . . . . . . . 12 100 8.2. Informative References . . . . . . . . . . . . . . . . . 12 101 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 103 1. Introduction 105 Traffic Engineered Networks can be interconnected, establishing 106 different types of relationships among them. For example, both 107 network can have a peering relation, where connections starting in 108 one domain and end in the other domain. This document is focused on 109 the case where the interconnected network domains have a client- 110 server relationship among them. Such client-server relation comes 111 from the two main points. On the one hand, end-to-end services in 112 the client network can be set up using services of a network acting 113 as server. On the other hand, the client-server relation comes from 114 the fact that their interconnection is a policy and administrative 115 boundary, limiting the amount of information allowed to be exchanged 116 between networks. In the case of interconnected TE domains where 117 there is no administrative nor strict policy boundary between client 118 and server (typically, just a technolgy change), the MLN/MRN model 119 can be applied. 121 The interface between the client and the server domain is typically 122 called "User-to-Network Interface" (UNI), and regarded as signaling- 123 only [RFC4208]. Due to the strict asociation of functionality to the 124 UNI term, its exact scope has become highly controversial. This 125 document compiles different definitions of the term used so far and 126 propose some terminology to serve as a foundation to move the work 127 forward. 129 What is more, the document compiles the possible operation models of 130 client-server network from the control plane perspective. Each 131 control model defines, on the one hand, the level of information of 132 the domain acting as client provides through the control plane to the 133 domain acting as server. On the other hand, the control model will 134 determine what can be requested from the client domain to the server 135 domain. 137 1.1. Examples of Client-Server TE Network Domain Scenarios 139 The most typical example of interconnected TE domains that follow a 140 client-server relation is an IP/MPLS domain using the services of an 141 optical OTN/WDM network. Note that the interconnected domain can be 142 part of the same organization, but with different administration. 144 A particular network scenario that has attracted lot of attention 145 from the industry is the IP/MPLS/OTN/WDM over WDM. The client 146 network is based on multi-layer routers able to set up packet-based 147 TE connections over wavelengths. The server network is a WDM optical 148 network that provides the switching for the wavelenghts as well as 149 restoration capabilities of the optical channels. 151 Another example is MPLS over MPLS, where both client and server 152 networks are able to set up packet based TE connections. This is the 153 case, for example, of carrier-over-carrier scenarios. 155 Summing up, there number of applicable scenarios is wide. 157 2. Terminology 159 2.1. Routing domain 161 A routing domain is made of GMPLS enabled nodes (i.e., a network 162 device including a GMPLS entity). These nodes can be either edge 163 nodes (i.e., hosts, ingress LSRs or egress LSRs), or internal LSRs. 164 An example of non-PSC host is an SONET/SDH Terminal Multiplexer (TM). 165 Another example is an SONET/SDH interface card within an IP router or 166 ATM switch. 168 A routing domain is characterized by being under the control of the 169 same administration and by running a common set of protocols to 170 exchange routing information 172 2.2. Overlay of routing domains 174 In an overlay environment we have a client routing domain and a 175 server routing domain, each of which running its own routing protocol 176 instance. Connectivity in the client routing domain can be made by 177 connectivity services of the server domain. 179 2.3. Multilayer 181 As per RFC 5212 "UA data plane layer is a collection of network 182 resources capable of terminating and/or switching data traffic of a 183 particular format [RFC4397]. These resources can be used for 184 establishing LSPs for traffic delivery. For example, VC-11 and 185 VC4-64c represent two different layers."U 187 In a Multilayer network, each layer can be or not a routing domain. 188 In fact, a multi-layer network can be controled with a single control 189 plane instance in which all resources are adverstised in the same IGP 190 instance 192 2.4. Policy 194 In an overlay network, policy is the set of rules that apply in the 195 interface between two routing domains, and that restrict the level of 196 information exchanged and the operations allowed. The policy 197 decisions obey to confidentiality reasons (typically, the routing 198 domains operate under the control of different administrations) and 199 scalability (to avoid excessive flow of information that collapse the 200 processing capacity of the nodes) 202 An example of policy example, visibility of the server domain could 203 be restricted to the client domain. 205 2.5. Client Domain - Server Domain Interface 207 The interface between the client and the server domain is typically 208 called "User-to-Network Interface" (UNI). However, the term "UNI" 209 has been used in different contexts and SDOs. As a consequence, the 210 exact definition of UNI and the functionalities included depend on 211 the application. Bellow, as a reference, it is shown a set of the 212 different definitions of UNI. 214 2.5.1. UNI in IP over Optical Networks 216 [RFC3717] says: "The client-optical internetwork interface (UNI) 217 represents a service boundary between the client (e.g., IP router) 218 and the optical network. The client and server (optical network) are 219 essentially two different roles: the client role requests a service 220 connection from a server; the server role establishes the connection 221 to fulfill the service request -- provided all relevant admission 222 control conditions are satisfied." 224 In other words, this definition refers to a signaling protocol 225 between two administrative domains with a client-server relationship. 226 It is agnostic to the existence of a data plane client-server 227 relationship and to the side(s) of the boundary where it may happen, 228 if any. 230 2.5.2. ITU-T Definition of UNI 232 ITU-T has defined the term UNI in the context of control plane. 233 [G.807] [G.8081] (ITU-T): "User-Network Interface for the control 234 plane (UNI): A bidirectional signaling interface between service 235 requester and service server control plane entities." 237 The terms "requester/provider" are used to refer to the relationship. 239 2.5.3. OIF Definition of UNI 241 UNI: "The service control interface between a client device and the 242 transport network." 244 UNI-C: "The logical entity that terminates UNI signalling on the 245 client device side." 247 UNI-N: "The logical entity that terminates UNI signalling on the 248 transport network side." 250 The terms "client/transport" and "client/network" are used to refer 251 to the relationship. 253 2.5.4. Proposed Vocabulary 255 As listed above, the existing terminology is far from unique. To 256 avoid overloaded concepts, this document proposes to use the "client/ 257 server" terms. 259 Unless stated, this document focuses on control protocol exchanges 260 and their uses across administrative boundaries for client-server 261 interconnection. Data plane transition and/or client-server 262 relationship may not be aligned with the boundary. 264 2.5.4.1. Client network 266 A Client network is defined as a network domain able to request a 267 connectivity service to a server network domain across an 268 administrative boundary. 270 2.5.4.2. Server network 272 A Server network is defined as a network domain able to deliver 273 connectivity services to a client network domain across an 274 administrative boundary. 276 2.5.4.3. Client-Server Control Plane Interface 278 The control plane interface between the client network domain and the 279 server network domain convey a set of control functionalities that 280 help to operate such kind of networks. The exact functionalities of 281 this Interface (and then the level of information exchanged) depend 282 on the chosen control model. This document presents a taxonomy with 283 the possible control models. 285 2.6. Reachability 287 In graph theory, reachability refers to the ability to get from one 288 vertex to another within a graph. Thus, a vertex can reach another 289 vertex if there exists a sequence of adjacent vertices which starts 290 with the source vertex and ends with the destination vertex. 292 The document [draft-farrel-interconnected-te-info-exchange-04] 293 provides the definition of what is reachability for client-server 294 networks. [EDITOR's note: Text from draft-farrel-interconnected-te- 295 info-exchange has been borrowed for this first version. Duplicated 296 text will be deleted at later stages] 298 In an IP network, reachability is the ability to deliver a packet to 299 a specific address or prefix. That is, the existence of an IP path 300 to that address or prefix. TE reachability is the ability to reach a 301 specific address along a TE path. 303 In the context of Traffic Engineered networks with client and server 304 relationships, we can define several types of reachability: 305 [draft-farrel-interconnected-te-info-exchange-04] 307 2.6.1. Unqualified Reachability 309 Two client domain nodes are said to be reachable if, either there 310 exists at least one path through the client domain that connects both 311 nodes, or, in the case that there is no path exclusively through the 312 client domain network, there exists al least one path connecting 313 nodes of client and server domain by which both client nodes can be 314 connected. 316 In the case of basic reachability, it is only known that it is 317 possible to connect the nodes, but there is no notion of the details 318 of such possible connections, such as, for example, bandwidth 319 available or performance metrics. Also, the exact path to connect 320 both nodes is not known to the client network. Note that, even if 321 two nodes are reachable, there may not be enough resources for a 322 desired TE connection with specific TE constraints. 324 2.6.2. Qualified Reachability 326 In this case, on top of the basic reachability, it is known some TE 327 attributes of the possible connection (or connections). Examples of 328 such attributes are: TE metrics, hop count, available bandwidth, 329 delay, SRLG list. Note that this information is specific per 330 connection. Thus, if there are several possible TE paths, there are 331 a set of attributes. 333 2.6.3. Qualified Reachability with associated potential TE path 335 In this particular case, on top of the qualified reachability, there 336 exists an associated potential TE path that satisfies the TE 337 connection between two client nodes. Thus, in this case, the client 338 Network has the information that there exists a TE path that can be 339 set up at any time. 341 3. Control Models 343 The control of the networks formed by interconnected domains with a 344 client-server relations between them can be done following different 345 models. Each control model defines, on the one hand, the level of 346 information that the domain acting as client receives by control 347 plane means about the services given by the domain acting as server. 348 This information, for example, can vary from a complete lack of 349 information, so the client domain only knows that it could be 350 possible to reach another point of its domain via the server network, 351 to a detailed view on the possibilities offered by the server 352 network. The level of detail of this information will determine 353 which information is exchanged between both networks. On the other 354 hand, the control model will determine what can be requested from the 355 client domain to the server domain. As an example, the most basic 356 use is specifying just the end-points to connect. Other cases may 357 include the possibility to request a service specifying a set of 358 constraints, like bandwidth, diversity, an optimization criteria, 359 etc. 361 Which control model to choose depends on several factors. For the 362 network operators, the main concern will be related to the level of 363 trustness and relationship between client and server domains. Also, 364 one key factor to take into account is the protocol interoperability. 365 Note that, equipment in the interconnected domains may be from 366 different technologies (but not necessarily) and are likely to use 367 different implementations. The higher the level of functionality 368 included in the control plane, the higher the protocol 369 interoperability requirements, as it will force all implementations 370 to support many functionality. Finally, scalability, that is, the 371 ability of the control plane to provide the same functionality 372 regarding the number of equipment, needs to be taken into account: 373 the amount of information in each option will have different limits 374 in terms on number of interconnected nodes. 376 3.1. Signaling Only 378 This first model considers that the sole functionality allowed in the 379 control plane is signaling, that is the ability to request services 380 from client to server domain. 382 In this model, the control plane does not provide a priori hints to 383 the client domain about the state of the server domain (e.g., 384 resource availability). This model does not preclude that, by other 385 means like the management plane, the client domain knows what is 386 possible or not. Such management actions are out of the scope of the 387 control plane. Thus, it is perfectly feasible that the reachability 388 information is provided either statically or by some management 389 platform. 391 The most basic case relies on sending a loose ERO from the client, 392 specifying the edges of the connection. 394 In a trusted interconnection mode, the signaling allows the client 395 domain to provide a full ERO, given to the client network by external 396 tools. 398 3.1.1. Signaling with Requirements 400 The control plane may allow to express complex requests to the server 401 domain. That is, through the signaling protocol, it is allowed to 402 not only request a connection between two points of the client 403 domain, but also to include some constraints: e.g., minimum 404 bandwidth, maximum delay, optimization criteria, or request diversity 405 from another service. The policy at the edges of the server network 406 will determine which constraints are accepted. Note the many of the 407 requirements that can be expressed in the request are similar to what 408 would be asked to a path computation function. 410 3.1.2. Signaling with Collection 412 Even though the only protocol enabled is signaling, it may be 413 beneficial for the client domain to be able to know some updated 414 information of the services that it has requested to the server. 415 Thus, this case considers the possibility that, through the signaling 416 protocol, the client domain can receive some information. What 417 information it is allowed to collect will be determined by the policy 418 of the server domain. 420 3.2. Signaling and Reachability Model 422 This second model considers that, in addition to signaling, the 423 client domain receives some reachability information through a 424 control plane mechanism. 426 3.2.1. Signalling + Basic Reachability 428 In this particular case, through control plane mechanisms, the client 429 domain knows whether it is possible to reach a remote end point. The 430 client domain should also remain aware of this information if there 431 are failures in the server domain or if the associated capacity has 432 been filled. 434 3.2.2. Signalling + Qualified Reachability 436 The control plane will provide information not only about the 437 possibility to reach a remote end point, but also some TE information 438 of possible connections. For example, the client domain will know 439 that it is possible to reach another point with some bandwidth or 440 delay. Note that, in this case, such information is sent by control 441 plane mechanisms (not statically configured by managament plane). 443 3.2.3. Signalling + Qualified Reachability + Potential Services 445 In addition to the TE information of the possible connections between 446 two points, the control plane will also provide to the client domain 447 information about potential server's services which could satisfy 448 given requirements. By control plane procedures, the client domain 449 can request, with respect to its needs, a service using such 450 potential service and make high level path selection within the 451 server domain. 453 3.3. Service Atributes vs service constraints 455 When asking for the setup of a service in the server domain, the 456 client domain can put constraints on such request. Constraints can 457 consist on the utilization of a path that minimizes a given metric 458 (e.g. TE metric or end to end delay) or on a set of lower/upper 459 bounds that must be followed (e.g. maximum number of hops or maximum 460 end to end delay). Once the service has been provisioned (or just 461 its paths computed), it is possible to identify (e.g. measure or 462 collect) the attributes that characterize such service. For example 463 the path has been computed so to meet the constraint of maximum end 464 to end delay of 20ms, while one of its attributes is the effective 465 end to end delay that is experimented along its path, which could be 466 of e.g. 14 ms. Other examples of constraints and attributes can be 467 found in path diversity. A typical constraint in LSP provisioning is 468 diversity, which is a constraint, but then attributes of the two 469 diverse LSPs like e.g. SRLGs can be collected. Both constraints and 470 attributes need to be exchanged between a client and a server domain. 472 3.4. Other Models 474 3.4.1. Multi-Layer Networks / Multi-Region Networks 476 MLN/MRN extensions to control protocols have been defined. They are 477 well scoped for client and server data plane domains without 478 administrative boundary between them. This allows MLN nodes to 479 participate in common control protocol instances. There is a full 480 set of mechanisms to operate such networks [Editor's note: add refs 481 to MLN/MRN)]. Typical use cases are switches combining both low- and 482 high-order Sonet/SDH, or both ODUk and wavelengths. 484 However, MLN/MRN assumes no policy boundary between client and server 485 domains. Thus, the level of information exchanged is not restricted, 486 and full interoperability of both the signaling and routing protocols 487 is required. 489 3.4.2. Management Model 491 In this particular case, the role of the control plane is limited to 492 operate independently in each of the domains. [Editor's note: Common 493 Control... WG => do we leave it?] 495 4. Abstraction 497 Abstraction: 499 - a physical topology is made of actual nodes interconnected by 500 existing links, i.e. without abstraction; 502 - a virtual topology is made of nodes and/or links which may (or may 503 not) exist or be instanciated to look the same as the advertised 504 abstraction; 506 - a potential topology is made of nodes and/or links which are not 507 existing at advertising time but could be instantiated on demand, 508 i.e. a virtual topology which can be actually provided by a network. 510 5. Security Considerations 512 TBD 514 6. Contributing Authors 515 7. Acknowledgments 517 The authors would like to thank Lou Berger for pointing out the 518 direction of the document and Dieter Beler for his review. The 519 authors would like to specially thank all the authors of draft- 520 farrel-interconnected-te-info-exchange-02 522 8. References 524 8.1. Normative References 526 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 527 Requirement Levels", BCP 14, RFC 2119, March 1997. 529 [RFC3107] Rekhter, Y. and E. Rosen, "Carrying Label Information in 530 BGP-4", RFC 3107, May 2001. 532 [RFC3717] Rajagopalan, B., Luciani, J., and D. Awduche, "IP over 533 Optical Networks: A Framework", RFC 3717, March 2004. 535 [RFC4208] Swallow, G., Drake, J., Ishimatsu, H., and Y. Rekhter, 536 "Generalized Multiprotocol Label Switching (GMPLS) User- 537 Network Interface (UNI): Resource ReserVation Protocol- 538 Traffic Engineering (RSVP-TE) Support for the Overlay 539 Model", RFC 4208, October 2005. 541 8.2. Informative References 543 [draft-farrel-interconnected-te-info-exchange-04] 544 "Farrel, A., Drake, J., Bitar, N., Swallow, G., 545 Ceccarelli, D. draft-farrel-interconnected-te-info- 546 exchange-04 Problem Statement and Architecture for 547 Information Exchange Between Interconnected Traffic 548 Engineered Networks", 2014. 550 Authors' Addresses 552 Oscar Gonzalez de Dios (editor) 553 Telefonica GCTO 554 Dis 555 Madrid 28045 556 Spain 558 Phone: +34913128832 559 Email: oscar.gonzalezdedios@telefonica.com 560 Julien Meuric (editor) 561 Orange 562 2 avenue Pierre Marzin 563 Lannion 22300 564 France 566 Email: julien.meuric@orange.com 568 Daniele Ceccarelli 569 Ericsson 570 Via Calda 5 571 Genova 572 Italy 574 Phone: +39 010 600 2512 575 Email: daniele.ceccarelli@ericsson.com