idnits 2.17.1 draft-grampin-pce-mgmnt-if-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 14. -- Found old boilerplate from RFC 3978, Section 5.5 on line 366. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document seems to lack an RFC 3979 Section 5, para. 1 IPR Disclosure Acknowledgement. ** The document seems to lack an RFC 3979 Section 5, para. 2 IPR Disclosure Acknowledgement. ** The document seems to lack an RFC 3979 Section 5, para. 3 IPR Disclosure Invitation. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 62 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 == Line 47 has weird spacing: '...), with a sta...' == 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 (July 2005) is 6860 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) -- Possible downref: Non-RFC (?) normative reference: ref. 'PCE-ARCH' -- Possible downref: Non-RFC (?) normative reference: ref. 'PCE-COMM-REQ' ** Obsolete normative reference: RFC 3784 (Obsoleted by RFC 5305) ** Obsolete normative reference: RFC 3768 (Obsoleted by RFC 5798) -- Possible downref: Non-RFC (?) normative reference: ref. 'PCE-DISC-REQ' Summary: 10 errors (**), 0 flaws (~~), 5 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 PCE Working Group 3 Internet Draft Eduardo Grampin 4 Document: draft-grampin-pce-mgmnt-if-00.txt UdelaR 5 Expires: January 2006 July 2005 7 PCE Management Interface 9 Status of this Memo 11 By submitting this Internet-Draft, each author represents that any 12 applicable patent or other IPR claims of which he or she is aware 13 have been or will be disclosed, and any of which he or she becomes 14 aware will be disclosed, in accordance with Section 6 of BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 Abstract 33 The Path Computation Element (PCE) Architecture provide a framework 34 to support the Constraint-Based Routing (CBR) functionality for 35 traffic engineering systems in Multiprotocol Label Switching (MPLS) 36 and Generalized Multiprotocol Label Switching (GMPLS) networks. 37 The model define the PCC and PCE entities at the Control Plane, which 38 communicate using a Request/Reply protocol. 39 The PCE architecture enable network operators a tight control of the 40 resource assignment by means of the administrative constraints that 41 are included in the Traffic Enginnering Database (TED), and used in 42 the path computation process. Moreover, appropriate objective 43 funtions assist operators in the fulfillment of the overall network 44 objectives. 46 This document present a system architecture for the PCE, namely 47 Routing and Management Agent (RMA), with a standard management 48 interface, which permit established management frameworks to rely on 49 the PCE for the CBR functionality and inject network-wide policies 50 into the PCE path computation process. Some reliability issues of the 51 PCE Architecture are addressed in the document. 53 Conventions used in this document 55 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 56 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 57 document are to be interpreted as described in RFC-2119 [i]. 59 Table of Contents 61 1. Introduction................................................2 62 2. RMA Functional Components....................................3 63 2.1 Signalling Interface....................................4 64 2.2 IGP Interface...........................................4 65 2.3 CBR Computation Component................................4 66 2.4 Traffic Engineering DataBase Component...................4 67 2.5 Management Plane Interface...............................4 68 3. Two Tier RMA Architecture....................................5 69 3.1 RMA availability and fault-tolerance.....................5 70 3.2 Traffic Engineering Database (TE-DB).....................6 71 3.3 The CBR process.........................................7 72 4. Autodiscovery of RMAs.......................................7 73 5. Security Considerations.....................................7 74 6. Acknowledgments.............................................7 75 7. References..................................................7 76 8. Author's Addresses..........................................8 77 9. Full Copyright Statement....................................8 79 1. Introduction 81 The Routing and Management Agent (RMA), interacts with both the 82 Control Plane and the Management Plane, assuming the PCE role in the 83 PCE Architecture [PCE-ARCH], as shown in Figure 1. 85 This entity, while enabling a Control Plane-based provisioning, can 86 be used as a traffic engineering tool by management applications, 87 using its interface towards the Management Plane. This interface can 88 be used to establish cooperative relationship with other RMAs in the 89 "multi-PCE path computation with PCE-intercommunication model" , as 90 specified in [PCE-ARCH]. 92 The RMA management interface is reachable in the management DCN, 93 therefore integrating the RMA into a distributed management 94 framework. 96 +------------------------+ 97 | Management Framework | 98 +------------------------+ 99 | 100 Management Interface 101 | 102 | 103 +------------------------------+ 104 | Routing and Management Agent | 105 +------------------------------+ 106 | 107 Control Plane Interface 108 | 109 | 110 +------------------+ 111 | Network Elements | 112 +------------------+ 114 Figure 1. Routing and Management Agent (RMA) 116 2. RMA Functional Components 118 The RMA is built asuming a component-based framework, with basic 119 scheduling and other supporting modules needed to build the described 120 functionality. The interfaces and "core" components shown in Figure 2 121 are described below: 123 +-------------------------------------------+ 124 | +----------------------+ | 125 | | Management Interface | | 126 | +----------------------+ | 127 | +-----------+ +--------------------+ | 128 | |CBR | |Traffic Engineering | | 129 | |Component | |Data Base | | 130 | +-----------+ +--------------------+ | 131 | +-----------+ +--------------------+ | 132 | |Signalling | |IGP +---+ | | 133 | |Interface | |Interface |TDB| | | 134 | | | | +---+ | | 135 | +-----------+ +--------------------+ | 136 +-------------------------------------------+ 137 Figure 2. RMA Functional Components 139 2.1 Signalling Interface 141 This component interfaces with PCCs via a suitable Request/Reply 142 protocol, as required by [PCE-COMM-REQ], and is out of the scope of 143 this document. 145 2.2 IGP Interface 147 The RMA gathers network topology running an instance of the network 148 TE IGP (OSPF-TE [RFC3630] or ISIS-TE [RFC3784]), communicating 149 through this interface. The RMA is like any node in the routing 150 graph, usually without forwarding capabilities, even though the PCE 151 functionality is orthogonal to packet forwarding, as defined in [PCE- 152 ARCH]. The goal of this component is to maintain the Topology 153 DataBase (TDB), which in turn is used to feed the Traffic Engineering 154 DataBase (TE-DB), the basic information source for CBR computation. 156 2.3 CBR Computation Component 158 This is the core of the RMA, which provides the intended 159 functionality: a computation engine for Constraint-Based Routing. The 160 component implements the needed algorithms to solve the Path 161 Computation problem with multiple restrictions. Well-known algorithms 162 and heuristics can be used to accomplish the intended goal, making 163 sure that route computation time is limited (i.e. by the usage of 164 polynomial-time CBR algorithms). 166 The two tier architecture with a computation cluster is presented in 167 Section 3 is able to fulfill this objective. 169 2.4 Traffic Engineering DataBase Component 171 The TE-DB contains the up-to-date information regarding link states 172 in the network, gathered by the IGP Interface. Additional 173 information, like constraints and administrative policies can also be 174 made persistent in the TE-DB. This information, which defines the TE 175 objectives of the network, will typically come from Policy-Based 176 Management applications. 178 2.5 Management Plane Interface 180 This component implements the interaction with management 181 applications, which enables the RMA to be used as a traffic 182 engineering component for high-level applications. Other 183 possibilities of this interface include the usage of the RMA as a 184 network-wide monitoring agent. 186 This interface may be based in well-known distributed component 187 frameworks like CORBA, widely used by telecommunication operators, 188 and/or J2EE, .NET or other usual packages in use in the enterprise 189 and Internet environments. 191 The information model used in this interfaces, as well as object 192 access granularity issues (coarse or fine grain) are out of the scope 193 of this document, and may be further standardized. 195 3. Two Tier RMA Architecture 197 The RMA is designed as a component-based system, as detailed in the 198 previous section. As described in other documents of the PCE WG, 199 several issues arise regarding the design and implementation of a PCE 200 Architecture; in particular availability and fault tolerance are of 201 major impact in network operation. This section review some of these 202 problems and propose some implementation guidelines. 204 3.1 RMA availability and fault-tolerance 206 A PCE centralized solution may suffer potential bottleneck problems 207 and is a single point of failure is not careful designed. 209 A Two Tier Architecture comprises a reliable communication front-end 210 with a computation back-end cluster, where the well-known High 211 Performance Computing paradigm may be of use. This architecture is 212 shown in Figure 3. This is a proven architecture used by Service and 213 Content Providers for high-availability services such as web-server 214 farms, VoD headends, E-Mail distributed servers. In the figure there 215 are two front-end sets, one to handle Control Plane communication, 216 and the other for the Management Plane. This separation, while not 217 mandatory, is advisable given that very different kind of protocols 218 need to be supported. 220 High availavility is given by two factors: 222 a) arbitrary large set of front-end (i.e. signaling) processors and, 223 b) arbitrary large set of computation nodes in the back-end cluster. 225 The remaining point of failure is network connectivity (both internal 226 and external). Internal connectivity (i.e. between front and back- 227 ends) can be protected by redundant LAN switches, while different 228 options exist to overcome potential external connectivity failure. A 229 straightforward (and expensive) solution is to place disjoint RMA 230 clusters in the network, while an acceptable solution would be to 231 have a multi-homed approach, i.e. use multiple load-sharing links. 232 Other useful techniques include VRRP [RFC3768] and DNS Round-Robin, 233 among others. 235 +----------------------+ 236 | Management Framework | 237 +---------|------------+ 238 +------------+--------------------------------------------+ 239 | | | 240 | +---------+---------+ +----------------------+ | 241 | | Management Plane | | Computation Cluster | | 242 | | Comm. Front-End | | | | 243 | +-------------------+ +----------------------+ | 244 | | Internal bus | | 245 | ''''''''''''''''''''''''''''''''''|''''''''''''''''''' | 246 | +-----------------+ | 247 | | Control Plane | | 248 | | Comm. Front-End | | 249 | +-------+---------+ | 250 +------------------------------------+--------------------+ 251 | 252 +--------+-----------+ 253 | Netwkork Elements | 254 +--------------------+ 255 Figure 3 - Two Tier RMA Architecture 257 3.2 Traffic Engineering Database (TE-DB) 259 The construction of the TE-DB involves two asynchronous process: 261 a) update of Topology Database (TDB) by the IGP 262 b) policy and administrative information insertion from management 263 applications. 265 The topology database (TDB) suffer intrinsic innacuracies, due to the 266 update mechanisms of the IGPs and the hierarchical routing approach 267 with information summarization. Some form of inaccuracy reduction 268 shall be implemented to reduced the gap between the gathered TDB and 269 the actual network state. This, consequently, will reduce the 270 blocking probability and the need for cranckback procedures in 271 provisioning time. 273 Policy and administrative information is inserted in the TE-DB by 274 management processes. Policy-Based Network Management enable network 275 administrators to manage network behaviour using high-level 276 definitions, or policies, which shall be expressed unambiguously. 277 These policies, associated with an abstract model of the managed 278 objects and accurate network status information permit to trigger or 279 refrain certain actions on network elements, resulting in an 280 enforcement of the high level policies. The policy language and 281 information model is out of the scope of this proposal. 283 Typical administrative information comprises link resource class 284 (colour), SRLGs, etc, while a simple routing policy is to deny the 285 establishment of LSPs with bandwith grater than a certain value, to 286 tune the load sharing of traffic demands and minimize blocking 287 probability. 289 3.3 The CBR process 291 There are a number of heuristics and a few exact algorithms to solve 292 the CBR process in near real time. The implementation shall evaluate 293 the applicable approaches to the RMA, taking into account the 294 objective functions, the system of demands, network and 295 administrative constraints that need to be satisfied. 297 4. Autodiscovery of RMAs 299 Autodiscovery requirements are defined in [PCE-DISC-REQ]. The RMA 300 architecture could implement a very basic static strategy, relying on 301 LSRs' local configuration; since the RMA architecture is redundant 302 and fault-tolerant, this may be considered a minor drawback. 304 5. Security Considerations 306 A potential security issue is raised by the fact that the proposed 307 architecture has connections to the network elements via the Control 308 Plane interface, and to the management applications via the 309 Management Plane interface. Specially crafted packets in the Control 310 Plane could eventually be used to gain access to the RMA with 311 potential incidence in network management applications. This is for 312 further study. 314 6. Acknowledgments 316 The author would like to express his warmest thanks to Joan Serrat, 317 Javier Baliosian, and the networking team at UdelaR for their 318 support, review and valuable suggestions. 320 7. References 322 i Bradner, S., "Key words for use in RFCs to Indicate Requirement 323 Levels", BCP 14, RFC 2119, March 1997 325 [PCE-ARCH] Farrel, A., Vasseur, JP, Ash, J., "Path Computation 326 Element (PCE) Architecture", work in progress. 328 [PCE-COMM-REQ] Ash, J., Le Roux JL, "Path Communication Protocol 329 Generic Requirements", work in progress. 331 [RFC3630] Katz D., Kompella K., Yeung D., "Traffic Engineering (TE) 332 Extensions to OSPF Version 2", RFC 3630, September 2003. 334 [RFC3784] Smit H., Li T., "Intermediate System to Intermediate System 335 (IS-IS) Extensions for Traffic Engineering (TE)", RFC 3784, June 336 2004. 338 [RFC3768] Hinden R. et al., "Virtual Router Redundancy Protocol 339 (VRRP)", RFC 3768, April 2004. 341 [PCE-DISC-REQ] Le Roux, JL, et. al., "Requirements for Path 342 Computation Element (PCE) Discovery," work in progress. 344 8. Author's Addresses 346 Eduardo Grampin 347 Universidad de la Republica - UdelaR 348 J.H. Reissig 565 349 11300 Montevideo - Uruguay 350 Email: grampin@fing.edu.uy 352 9. Full Copyright Statement 354 Copyright (C) The Internet Society (2005). 356 This document is subject to the rights, licenses and restrictions 357 contained in BCP 78, and except as set forth therein, the authors 358 retain all their rights. 360 This document and the information contained herein are provided on an 361 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 362 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 363 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 364 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 365 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 366 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.