idnits 2.17.1 draft-liu-i2rs-architecture-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 : ---------------------------------------------------------------------------- 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 (July 8, 2013) is 3938 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC2328' is defined on line 244, but no explicit reference was found in the text == Unused Reference: 'RFC4271' is defined on line 246, but no explicit reference was found in the text Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 I2RS D. Liu 3 Internet-Draft China Mobile 4 Intended status: Informational B. Khasnabish 5 Expires: January 9, 2014 ZTE 6 H. Deng 7 China Mobile 8 July 8, 2013 10 Architecture Discussion of I2RS 11 draft-liu-i2rs-architecture-01 13 Abstract 15 This document discusses the high level architecture of I2RS. We plan 16 to include discussion on virtualization, service chaining, and 17 grouping in a future version of this draft. 19 Status of this Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on January 9, 2014. 36 Copyright Notice 38 Copyright (c) 2013 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 2. Conventions used in this document . . . . . . . . . . . . . . . 4 55 3. Architecture of I2RS . . . . . . . . . . . . . . . . . . . . . 5 56 4. I2RS Application/Agent . . . . . . . . . . . . . . . . . . . . 6 57 5. I2RS Interfaces . . . . . . . . . . . . . . . . . . . . . . . . 6 58 6. Network/Service Control . . . . . . . . . . . . . . . . . . . . 6 59 7. Management Considerations . . . . . . . . . . . . . . . . . . . 6 60 8. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 61 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 62 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 7 63 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 64 11.1. Normative References . . . . . . . . . . . . . . . . . . . 7 65 11.2. Informative References . . . . . . . . . . . . . . . . . . 7 66 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7 68 1. Introduction 70 This document discusses the high level architecture of I2RS. As 71 illustrated in figure 1, the I2RS architecture is composed by three 72 types of building blocks. The first type of the building block is 73 the user of I2RS interface. The users could be network controllers, 74 network management functions, other user applications etc. The user 75 application uses the I2RS interface interacts with the routing 76 system. The second type of the building block is management 77 functions. This include configuration management function and 78 security management function. The configuration management function 79 is used to configure the I2RS interface. The security function is 80 used to enforce the security polices of the I2RS interface. The 81 third type of the building block is routing function. This build 82 block includes routing information base, IP forwarding table etc. 83 The routing information base could be accessed by the I2RS users 84 using the I2RS interface. 86 Figure 1 architecture of I2RS 87 +------------------+ +------------------+ +-----------------+ 88 |Network Controller| |Network Management| | User Application|.. 89 +------------------+ +------------------+ +-----------------+ 90 | | | | 91 \---------------| |--------------------/ 92 | | I2RS Interface 93 +----------------------+ | | +------------------+ 94 |Configuration Function|----| |-----|Security Function | 95 +----------------------+ | | +------------------+ 96 | | 97 | | Routing Function 98 +---------------------------| |--------------------------------+ 99 | | | | 100 | +------------+ | | +-----------+ | 101 | |OSPF process| | | |BGP process| ... | 102 | +------------+ | | +-----------+ | 103 | | | | | | 104 | | +------------------------+ | | 105 | +-----|Routing Information Base|-------+ | 106 | +------------------------+ | 107 | | | 108 +---------------------------|----------------------------------+ 109 | 110 {OF, ForCES, .. Protocol} | Forwarding Function 111 +---------------------------|----------------------------------+ 112 | | | 113 | | | 114 | +--------------------+ | 115 | | IP Forwarding Table| | 116 | +--------------------+ | 117 | | 118 +--------------------------------------------------------------+ 120 Figure 1 122 2. Conventions used in this document 124 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 125 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 126 document are to be interpreted as described in RFC-2119 [RFC2119]. 128 In this document, these words will appear with that interpretation 129 only when in ALL CAPS. Lower case uses of these words are not to be 130 interpreted as carrying RFC-2119 significance. 132 A list of acronyms and abbreviations used in this document are 133 presented below. 135 o ForCES: Forwarding and Control Element separation 136 o I2RS: Interface to Routing System 137 o NSC: Network Service Chaining 138 o NSG: Network Service Grouping 139 o OF: Open Flow 140 o RIB: Routing Information Base 141 o TIB: Topology Information Base 143 3. Architecture of I2RS 145 This section discusses the function of the building block of the I2RS 146 architecture. 148 i. I2RS user application 150 The I2RS user application communicate with the routing information 151 base using the I2RS interface. The user application can read the 152 routing information from the routing information base, it can also 153 inject polices, routing information etc into the routing information 154 base. The I2RS interface could be RESTful API or websocket etc. 155 There should be an authentication mechanism in the I2RS architecture 156 that only allow the authorized application communicate with the 157 routing system. 159 ii. Configuration function 161 The I2RS interface could be configured by the configuration function. 162 The I2RS user application could customize the I2RS interface function 163 and set the I2RS interface parameters by the configuration function. 165 iii. Security function 167 Security function is an important building block of the I2RS 168 architecture. It will ensure only authorized application can use the 169 I2RS interface and communicate with the routing system. There could 170 be different level of authorization. For example, the security 171 function can allow some application only read from the routing system 172 while other application can both read and inject polices into the 173 routing system. 175 iv. Routing function 177 The routing function is composed of routing information base (RIB), 178 IP forwarding table and the routing processes. The I2RS application 179 could communicate with the routing information base using the I2RS 180 interface. It can read or inject routing information into the 181 routing information base. The routing processes can also inject 182 routing information into the routing information base. 184 iv. Forwarding function 186 The forwarding function facilitates forwarding of flows/packets. It 187 can operate using simple Table or sophisticated dynamic matrix for 188 intelligent processing of flows. 190 4. I2RS Application/Agent 192 This section discusses the I2RS application and agent function in the 193 architecture. There are many applications can use the I2RS 194 interfaces. For example, network management application can use I2RS 195 interface to get the network topology information. I2RS agent 196 locates in the routing function and communicates with the I2RS 197 application. 199 5. I2RS Interfaces 201 This section discusses the I2RS interfaces in the architecture. The 202 I2RS interface is the interface between the I2RS application and the 203 I2RS agent. 205 6. Network/Service Control 207 This section discusses the network and service control in the 208 architecture. Network control may include control of both virtual 209 and physical network entities. The services may include chaining of 210 network services (NSCs) and grouping network services (NSGs). 212 7. Management Considerations 214 This section discusses the management consideration of the 215 architecture. In addition to managing the configurations of the 216 virtual and physical network entities, this may include managing 217 service-specific meta-data and configurations of the hosts that 218 provide network-based value-added services like policy, compliance, 219 load-balancing, and so on. 221 8. Security Considerations 223 Security function is very important for the I2RS architecture. It 224 should provide authentication mechanism and data protection mechanism 225 to protect critical routing information. 227 9. IANA Considerations 229 No IANA action is required. 231 10. Acknowledgments 233 . 235 11. References 237 11.1. Normative References 239 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 240 Requirement Levels", BCP 14, RFC 2119, March 1997. 242 11.2. Informative References 244 [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998. 246 [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway 247 Protocol 4 (BGP-4)", RFC 4271, January 2006. 249 Authors' Addresses 251 Dapeng Liu 252 China Mobile 253 Unit2, 28 Xuanwumenxi Ave,Xuanwu District 254 Beijing 100053 255 China 257 Email: liudapeng@chinamobile.com 258 Bhumip Khasnabish 259 ZTE 260 55 Madison Avenue, Suite 160 261 Morristown, New Jersey 07960 262 USA 264 Phone: +001-781-752-8003 265 Email: vumip1@gmail.com, bhumip.khasnabish@zteusa.com 267 Hui Deng 268 China Mobile 269 Unit2, 28 Xuanwumenxi Ave,Xuanwu District 270 Beijing 100053 271 China 273 Email: denghui@chinamobile.com 275 =