idnits 2.17.00 (12 Aug 2021) /tmp/idnits38582/draft-hares-i2rs-info-model-service-topo-03.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors 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 date (January 29, 2015) is 2662 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 I2RS working group S. Hares 3 Internet-Draft Q. Wu 4 Intended status: Standards Track M. Wang 5 Expires: August 2, 2015 J. You 6 Huawei 7 January 29, 2015 9 An Information model for service topology 10 draft-hares-i2rs-info-model-service-topo-03 12 Abstract 14 As stated in [I.D-ietf-sfc-problem-statement], the service overlay is 15 independent of the network topology and allows operators to use 16 whatever overlay or underlay they prefer and to locate service nodes 17 in the network as needed. 19 This document extends the general topology model concept defined in 20 [I.D-medved-i2rs-topology-im] and focuses on defining information 21 model for service topology. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on August 2, 2015. 40 Copyright Notice 42 Copyright (c) 2015 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 58 2. Conventions used in this document . . . . . . . . . . . . . . 3 59 3. Service Topology Information Model . . . . . . . . . . . . . 3 60 3.1. Model Overview . . . . . . . . . . . . . . . . . . . . . 3 61 3.2. Abstract Topology Model: the Service-Topology Component . 3 62 3.3. Model Extension: Service Function Chain Topology 63 Component . . . . . . . . . . . . . . . . . . . . . . . . 7 64 3.4. Model Extension: Inventory datastore Component . . . . . 8 65 4. Security Considerations . . . . . . . . . . . . . . . . . . . 9 66 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 67 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 68 6.1. Normative References . . . . . . . . . . . . . . . . . . 9 69 6.2. Informative References . . . . . . . . . . . . . . . . . 10 70 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 72 1. Introduction 74 Network topology information can be collected from network by using 75 IGP or BGP-LS [I.D-draft-ietf-idr-ls-distribution]. Information 76 model for network topology provided in [I.D-medved-i2rs-topology-im] 77 is built based on such network topology information. 79 A service specific overlay utilized by Service chaining creates the 80 service topology. The overlay creates a path between service 81 function(SF) nodes. Service functions can be co-located on one SF 82 Node or physically separated across several SF Nodes with each having 83 one or more Service Functions. In either case, a service function 84 may be running in its own virtualized system space or natively on the 85 hosting system. 87 Within the service topology, an ordered set of Service functions will 88 be invoked for each packet that belongs to a given flow for which a 89 SFC will be applied. Adding new service function to SF Node in the 90 topology is easily accomplished, and no underlying network changes 91 are required. Furthermore, additional service Functions or Service 92 Function instances, for redundancy or load distribution purpose, can 93 be added or removed to the service topology as required. 95 As stated in [I.D-ietf-sfc-problem-statement], the service overlay is 96 independent of the network topology and allows operators to use 97 whatever overlay or underlay they prefer and to locate service nodes 98 in the network as needed. 100 This document extends the general topology model concept defined in 101 [I.D-medved-i2rs-topology-im] and focuses on defining information 102 model for service topology. 104 2. Conventions used in this document 106 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 107 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 108 document are to be interpreted as described in RFC2119 [RFC2119]. 110 3. Service Topology Information Model 112 This section specifies the service topology information model in 113 Routing Backus-Naur Form (RBNF, [RFC5511]). It also provides 114 diagrams of the main entities that the information model is comprised 115 of. 117 3.1. Model Overview 119 The abstract Topology Model contain a set of abstract nodes and a 120 list of abstract links. An abstract link connects two abstract 121 nodes. Service Function Chain Topo model and other service topo 122 model can be augumented from the abstract topology model with 123 topology specifics. 125 +-----------------+ 126 | Abstract | 127 | Topology Model | 128 | | 129 +--------|--------+ 130 | 131 +------------------------+ 132 | | | 133 | | | 134 +--------V--------+ +--------V--------+ 135 |Service Function | | | 136 | Chain | | Other Service | 137 | Topology Model | | Topology Model | 138 +-----------------+ +-----------------+ 140 3.2. Abstract Topology Model: the Service-Topology Component 142 The following diagram contains an informal graphical depiction of the 143 main elements of the information model: 145 +----------------+ 146 | topology |<... 147 +----------------+ : 148 * * : : 149 | | :...: 150 | | 151 +--------+ +--------+ 152 ...>| node |<.......|segment |<... 153 : +--------+<.......+--------+ : 154 : : * : : * : : 155 :..... | : : | :...: 156 | : : | 157 .....>+--------+<........: : | 158 : | TP |<..........: | 159 : ...>+--------+ | 160 : : | 161 : : .....................+---------+ 162 .........................|Direction| 163 +---------+ 165 The basic information model works as follows: A service topology 166 contains service nodes and segments. A segment connects two nodes (a 167 source and a destination)and have direction, may be unidirectional or 168 bidirectional. unidirectional is one where traffic is passed through 169 any two service node or a set of service nodes in one forwarding 170 direction only. Bidirectional is one where traffic is passed through 171 any two service nodes or a set of service nodes in both forwarding 172 directions. Each serivce node contains termination points. It 173 occurs before or after other service node, therefore each node may 174 have its upstream service node and/or downstream service node. 176 A service node may be dedicated to a tenant(e.g., an IPVPN customer), 177 globally shared among tenants, or available to be assigned in whole 178 or in part to a tenant or a set of tenants. Therefore service Nodes 179 can map onto and be supported by other network elements in the 180 underlying network, while Segment can map onto and be supported by 181 other links in the underlying network,e.g., one segment can be mapped 182 to two consecutive links stitching together. Service Topologies can 183 map onto other, underlay topologies. 185 The information model for the Service-Topology component is more 186 formally shown in the following diagram. 188 /* exterior definitions for service topology */ 190 ::= (...) 192 /* Topology definitions */ 193 ::= 194 [] 195 (...) 196 (...) 197 [] 198 [] 199 [] 201 ::= INTEGER-32; 202 ::= ( 203 ( [])| 204 ( []) 206 ::= (...) 208 ::= 209 | 210 ... 211 ::= 212 213 214 [] 215 [ ] 217 ::= 218 ::= 220 ::= 222 ::= ()| 223 () 225 ::= | 226 | 227 ... 228 ::= 229 (...) 230 [] 231 [] 232 [] 234 ::= 235 [] 236 [] 237 ::= 238 (...) 239 < NODE-TYPE> ::= 240 ()| 241 ()| 242 () 243 ... 244 ::= (...) 245 ::= | 246 | 247 248 ... 250 The elements of the Service-Topology information model are as 251 follows: 253 o A service overlay can contain multiple topologies. Each topology 254 is captured in its own list element, distinguished via a topology- 255 id. 257 o A topology has a certain type, such as NETCONF or I2RS. A 258 topology can even have multiple types simultaneously. The type, 259 or types, are captured in the list of "topology-type" components. 261 o A topology contains segments and nodes, each captured in their own 262 list. 264 o A node has a node-id. This distinguishes the node from other 265 nodes in the list. In addition, a node has a list of termination 266 points, used to terminate segment. An examples of a termination 267 point might be a physical or logical port or, more generally, an 268 interface. 270 o A segment is identified by a segment-identifier, uniquely 271 identifying the portion of the network bounded by two service 272 nodes within the topology. segment are point-to- point and has 273 direction. The direction can be unidirectional or bidirectional. 274 Accordingly, a segment contains a source and a destination. Both 275 source and destination reference a corresponding node, as well as 276 a termination point on that node. 278 o The topology, node, segment and direction elements can be extended 279 with topology-specific components (topology-extensions, node- 280 extension, segment-extension and direction-extension 281 respectively). 283 The topology model includes segment that are either bidirectional 284 unidirectional. Service function chain path is analogue to linked 285 list data structure and can be represented through a set of Ordered 286 segments from source to destination. Each node in the service 287 overlay may be located at different layer. The segment can be setup 288 to steer traffic through these specific service nodes at different 289 layers or bypass some specific service nodes at different layers. 291 The topology model only supports point to point and does not support 292 multipoint. Therefore Segments are terminated by a single 293 termination point, not sets of termination points. Connections 294 involving multihoming or segment aggregation schemes need to be 295 modeled using multiple point-to-point segment,e.g., connection from 296 service node A at lower layer to service node D at higher layer can 297 comprise a segment 1 from service node A to service node B and 298 segment 2 from service node B to service node C and segment 3 from 299 service node C to service node D. By using segment aggregation, we 300 can define a new segment from service A to service node D which is 301 supported by segment 1,2 and 3. 303 Unlike network topology collection, the service topology information 304 may be not available from each SF by using IGP advertisement or BGP- 305 LS northbound distribution since SF may be not located at network 306 layer. However these SF at different layer may have affinity with 307 one SF node(e.g., SF egress node or SF ingress node or SF enabled 308 node),therefore service topology information associated with Service 309 nodes can be collected using RESTCONF/NETCONF interface or I2RS 310 interface for interrogation of a virtual device's state, statistics 311 and configuration. 313 3.3. Model Extension: Service Function Chain Topology Component 314 ::= 315 316 317 :: = 318 319 :: = 320 321 322 324 ::= 325 | 326 | 327 | 328 | 329 331 ::= 332 333 334 335 336 337 ::= 339 3.4. Model Extension: Inventory datastore Component 341 Inventory Data for service overlay can be obtained by using NETCONF 342 or I2RS and share to PCE, ALTO server or other topology manager 343 defined in [I.D-ietf-i2rs-architecture]. Information shared by them 344 is defined as the component, "inventory database". This component 345 defines a set of groupings with auxiliary information required and 346 shared by those other components. 348 ::= 349 350 352 ::= 353 ()| 354 ()| 355 ()| 356 () 358 :: = 359 ()| 360 ()| 361 ()| 362 ()| 363 ()| 364 ()| 365 ()| 366 ()| 367 ()| 368 ()| 369 () 371 This module details inventory node attributes: 373 o Inventory node attributes include SF-type,SF-capabilities and SF- 374 administrative-info. 376 4. Security Considerations 378 This document does not introduce any new security issues above those 379 identified in [RFC5511]. 381 5. IANA Considerations 383 This draft includes no request to IANA. 385 6. References 387 6.1. Normative References 389 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 390 Requirement Levels", March 1997. 392 [RFC5511] Farrel, A., "Routing Backus-Naur Form (RBNF): A Syntax 393 Used to Form Encoding Rules in Various Routing Protocol 394 Specifications", RFC 5511, April 2009. 396 6.2. Informative References 398 [I.D-bitar-i2rs-service-chaining] 399 Bitar, N., Heron, G., and L. Fang, "Interface to the 400 Routing System (I2RS) for Service Chaining: Use Cases and 401 Requirements", ID draft-bitar-i2rs-service-chaining-00, 402 July 2013. 404 [I.D-draft-ietf-idr-ls-distribution] 405 Gredler, H., "North-Bound Distribution of Link-State and 406 TE Information using BGP", ID draft-ietf-idr-ls- 407 distribution-03, May 2013. 409 [I.D-ietf-sfc-problem-statement] 410 Quinn, P., "Service Function Chaining Problem Statement", 411 ID draft-ietf-sfc-problem-statement-10, August 2014. 413 [I.D-medved-i2rs-topology-im] 414 Medved, J., Bahadur, N., Clemm, A., and H. 415 Ananthakrishnan, "An Information Model for Network 416 Topologies", ID draft-medved-i2rs-topology-im-01, October 417 2003. 419 Authors' Addresses 421 Susan Hares 422 Huawei 423 7453 Hickory Hill 424 Saline, MI 48176 425 USA 427 Email: shares@ndzh.com 429 Qin Wu 430 Huawei 431 101 Software Avenue, Yuhua District 432 Nanjing, Jiangsu 210012 433 China 435 Email: sunseawq@huawei.com 436 Michael Wang 437 Huawei 438 101 Software Avenue, Yuhua District 439 Nanjing, Jiangsu 210012 440 China 442 Email: wangzitao@huawei.com 444 Jianjie You 445 Huawei 446 101 Software Avenue, Yuhua District 447 Nanjing, Jiangsu 210012 448 China 450 Email: youjianjie@huawei.com