| I2RS | D. Liu |
| Internet-Draft | China Mobile |
| Intended status: Informational | B. Khasnabish |
| Expires: January 16, 2014 | ZTE |
| H. Deng | |
| China Mobile | |
| July 15, 2013 |
Architecture Discussion of I2RS
draft-liu-i2rs-architecture-02
This document discusses the high level architecture of I2RS. This document also provides brief descriptions on the use of virtualization and its impact on constructing chained and grouped services. We plan to include further details on virtualization, service chaining, and grouping in a future version of this draft.
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 16, 2014.
Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
This document discusses the high level architecture of I2RS. As illustrated in figure 1, the I2RS architecture is composed by three types of building blocks. The first type of the building block is the user of I2RS interface. The users could be network controllers, network management functions, other user applications etc. The user application uses the I2RS interface interacts with the routing system. The second type of the building block is management functions. This include configuration management function and security management function. The configuration management function is used to configure the I2RS interface. The security function is used to enforce the security polices of the I2RS interface. The third type of the building block is routing function. This build block includes routing information base, IP forwarding table etc. The routing information base could be accessed by the I2RS users using the I2RS interface. Besides, the routing control and the forwarding function could also be separated. The interface between the routing control and forwarding function could be open flow, ForCES etc.
+------------------+ +------------------+ +-----------------+
|Network Controller| |Network Management| | User Application|..
+------------------+ +------------------+ +-----------------+
| | | |
\---------------| |--------------------/
| | I2RS Interface
+----------------------+ | | +------------------+
|Configuration Function|----| |-----|Security Function |
+----------------------+ | | +------------------+
| |
| | Routing Function
+---------------------------| |--------------------------------+
| | | |
| +------------+ | | +-----------+ |
| |OSPF process| | | |BGP process| ... |
| +------------+ | | +-----------+ |
| | +--------+ | |
| | | Agent | | |
| | +--------+ | |
| | +----------|-------------+ | |
| +-----|Routing Information Base|-------+ |
| +------------------------+ |
| | |
+---------------------------|----------------------------------+
|
{OF, ForCES, .. Protocol} | Forwarding Function
+---------------------------|----------------------------------+
| | |
| | |
| +--------------------+ |
| | IP Forwarding Table| |
| +--------------------+ |
| |
+--------------------------------------------------------------+
Figure 1: architecture of I2RS
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119 [RFC2119].
In this document, these words will appear with that interpretation only when in ALL CAPS. Lower case uses of these words are not to be interpreted as carrying RFC-2119 significance.
A list of acronyms and abbreviations used in this document are presented below.
This section discusses the function of the building block of the I2RS architecture. These functional building blocks could be either physical or virtual or hybrid, i.e., a combination of physical and virtual blocks.
i. I2RS application
The I2RS applications communicate with the I2RS agent using the I2RS interface. The I2RS agent locates in the router that implement the I2RS interface. The I2RS agent communicates with the routing system. The interface between the I2RS agent and the routing system could be implementation specific. The I2RS application can read the routing information from the routing information base, it can also inject polices, routing information etc into the routing information base. The I2RS interface could be RESTful API or websocket etc. There should be an authentication mechanism in the I2RS architecture that only allow the authorized application communicate with the I2RS agent.
ii. Configuration function
The I2RS interface could be configured by the configuration function. The I2RS user application could customize the I2RS interface function and set the I2RS interface parameters by the configuration function. The network administrator can also use this configuration function to control the I2RS interface parameters. For example, the network administrator may need to control a certain scope of the routing information could be accessed by a specific I2RS application. The network administrator can use the configuration function to implement those settings.
Virtualization of the configuration function through appropriate management and/or visor function would help achieve (a) efficient management of configuration resources, and (b) desired chaining/grouping of the resources for dynamically balancing/distributing operational loads.
iii. Security function
Security function is an important building block of the I2RS architecture. It will ensure only authorized application can use the I2RS interface and communicate with the routing system. There could be different level of authorization. For example, the security function can allow some application only read from the routing system while other application can both read and inject polices into the routing system.
Virtualization of the security function would help move the service closer to the utilization point based on the desired requirements without moving the physical device (or installing new purpose-built devices).
iv. Routing function
The routing function is composed of routing information base (RIB), IP forwarding table and the routing processes. The I2RS application could communicate with the routing information base using the I2RS interface. The agent function locates in the router could communicate with the routing information base and the I2RS application. It receives the I2RS application's request and convert it to the implementation specific command to get/set the routing information base. By this way, the I2RS application can read or inject routing information into the routing information base. The routing processes can also inject routing information into the routing information base. There should be a protection mechanism to prevent any race condition of the routing information base be modified by different entities simultaneously. The Routing function can be virtualized.
iv. Forwarding function
The forwarding function facilitates forwarding of flows/packets. It can operate using simple Table or sophisticated dynamic matrix for intelligent processing of flows. The forwarding function can be virtualized.
This section discusses the I2RS application and agent function in the architecture. There are many applications can use the I2RS interfaces. For example, network management application can use I2RS interface to get the network topology information. I2RS agent locates in the routing function and communicates with the I2RS application. The I2RS agent locates in the router, it can communicate with the I2RS application using the I2RS interface. The I2RS agent convert the I2RS application's command into implementation specific functions to get/set the routing information base.
This section discusses the I2RS interfaces in the architecture. The I2RS interface is the interface between the I2RS application and the I2RS agent. The requirement of the I2RS interface includes the following aspects: (1) The I2RS interface should support multiplexing function that allows multiple I2RS applications communicate with one I2RS agent and one I2RS application communicates with multiple I2RS agents. (2) The I2RS interface should support authentication/authorization mechanism that allow only the authorized I2RS application access specific routing information. The I2RS interface should support encryption and data integrity protection mechanism. (3) The I2RS interface should support data protection mechanism to prevent the race condition. (4) The I2RS interface should provide scalability and extensibility.
This section discusses the network and service control in the architecture. Network control may include control of both virtual and physical network entities. The services may include chaining of network services (NSCs) and grouping network services (NSGs).
^
._._._._._._._._._._._._._._ |
| ---|----------------
------- ------- |Control/Managemnt |
<- |VNF-1| <- |VNF-n|._._._._| of VNFs |-->
| | ... | | | |
------- ------- --------------------
|.............|
|
|
/----------------\
| Virtualization/ |
| Abstraction |
\----------------/
|
|
...................
: Network :
: Function (NF) :
:.................:
Figure 2: Network Function Service Chaining
^
._._._._._._._._._._._._._._ |
| ---|----------------
------- ------- |Control/Managemnt |
<- |VSF-1| <- |VSF-n|._._._._| of VSFs |-->
| | ... | | | |
------- ------- --------------------
|.............|
|
|
/----------------\
| Virtualization/ |
| Abstraction |
\----------------/
|
|
...................
: Service :
: Function (SF) :
:.................:
Figure 3: Service Function Service Chaining
This section discusses the management consideration of the architecture. In addition to managing the configurations of the virtual and physical network entities, this may include managing service-specific meta-data and configurations of the hosts that provide network-based value-added services like policy, compliance, load-balancing, and so on.
Security function is very important for the I2RS architecture. It should provide authentication mechanism and data protection mechanism to protect critical routing information.
To be determined later.
.
| [RFC2119] | Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. |
| [RFC2328] | Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998. |
| [RFC4271] | Rekhter, Y., Li, T. and S. Hares, "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, January 2006. |
| [DMTF-DSP0243] | , , "DMTF DSP0243, Open Virtualization Format Specification 2.0", December 2012. |
| [DMTF-DSP0263] | , , "DMTF DSP0263, Cloud Infrastructure Management Interface (CIMI) Model and REST Interface over HTTP 1.0", September 2012. |
| [DMTF-DSP2029] | , , "DMTF DSP2029, Cloud Management for Communications Service Providers 1.0", January 2012. |
| [DMTF-DSP2034] | , , "DMTF DSP2034, Network Services Management Use Cases, 1.0a", March 2013. |