Routing Optimization with SDN in Data Center Networks
draft-kong-sdnrg-routing-optimization-sdn-in-dc-04
The information below is for an old version of the document.
Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Expired".
|
|
---|---|---|---|
Authors | Qian Kong , Tao Gao , Dajiang Wang , Zhenyu Wang , Jiayu Wang, Bingli Guo , Shanguo Huang | ||
Last updated | 2018-04-04 | ||
RFC stream | (None) | ||
Formats | |||
Additional resources | |||
Stream | Stream state | (No stream defined) | |
Consensus boilerplate | Unknown | ||
RFC Editor Note | (None) | ||
IESG | IESG state | I-D Exists | |
Telechat date | (None) | ||
Responsible AD | (None) | ||
Send notices to | (None) |
draft-kong-sdnrg-routing-optimization-sdn-in-dc-04
Network Working Group A. Rousskov Request for Comments: 4037 The Measurement Factory Category: Standards Track March 2005 Open Pluggable Edge Services (OPES) Callout Protocol (OCP) Core Status of This Memo This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. Copyright Notice Copyright (C) The Internet Society (2005). Abstract This document specifies the core of the Open Pluggable Edge Services (OPES) Callout Protocol (OCP). OCP marshals application messages from other communication protocols: An OPES intermediary sends original application messages to a callout server; the callout server sends adapted application messages back to the processor. OCP is designed with typical adaptation tasks in mind (e.g., virus and spam management, language and format translation, message anonymization, or advertisement manipulation). As defined in this document, the OCP Core consists of application-agnostic mechanisms essential for efficient support of typical adaptations. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Scope . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.2. OPES Document Map . . . . . . . . . . . . . . . . . . . 5 1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . 6 2. Overall Operation . . . . . . . . . . . . . . . . . . . . . . 7 2.1. Initialization . . . . . . . . . . . . . . . . . . . . . 7 2.2. Original Dataflow . . . . . . . . . . . . . . . . . . . 8 2.3. Adapted Dataflow . . . . . . . . . . . . . . . . . . . . 8 2.4. Multiple Application Messages . . . . . . . . . . . . . 9 2.5. Termination . . . . . . . . . . . . . . . . . . . . . . 9 2.6. Message Exchange Patterns . . . . . . . . . . . . . . . 9 2.7. Timeouts . . . . . . . . . . . . . . . . . . . . . . . . 10 2.8. Environment . . . . . . . . . . . . . . . . . . . . . . 11 3. Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 Rousskov Standards Track [Page 1] RFC 4037 OPES Callout Protocol Core March 2005 3.1. Message Format . . . . . . . . . . . . . . . . . . . . . 12 3.2. Message Rendering . . . . . . . . . . . . . . . . . . . 13 3.3. Message Examples . . . . . . . . . . . . . . . . . . . . 14 3.4. Message Names . . . . . . . . . . . . . . . . . . . . . 15 4. Transactions . . . . . . . . . . . . . . . . . . . . . . . . . 15 5. Invalid Input . . . . . . . . . . . . . . . . . . . . . . . . 16 6. Negotiation . . . . . . . . . . . . . . . . . . . . . . . . . 16 6.1. Negotiation Phase . . . . . . . . . . . . . . . . . . . 17 6.2. Negotiation Examples . . . . . . . . . . . . . . . . . . 18 7. 'Data Preservation' Optimization . . . . . . . . . . . . . . . 20 8. 'Premature Dataflow Termination' Optimizations . . . . . . . . 21 8.1. Original Dataflow . . . . . . . . . . . . . . . . . . . 22 8.2. Adapted Dataflow . . . . . . . . . . . . . . . . . . . . 23 8.3. Getting Out of the Loop . . . . . . . . . . . . . . . . 24 9. Protocol Element Type Declaration Mnemonic (PETDM) . . . . . . 25 9.1 Optional Parameters . . . . . . . . . . . . . . . . . 27 10. Message Parameter Types . . . . . . . . . . . . . . . . . . . 28 10.1. uri. . . . . . . . . . . . . . . . . . . . . . . . . . 28 10.2. uni. . . . . . . . . . . . . . . . . . . . . . . . . . 28 10.3. size . . . . . . . . . . . . . . . . . . . . . . . . . 29 10.4. offset . . . . . . . . . . . . . . . . . . . . . . . . 29 10.5. percent . . . . . . . . . . . . . . . . . . . . . . . 29 10.6. boolean. . . . . . . . . . . . . . . . . . . . . . . . 30 10.7. xid . . . . . . . . . . . . . . . . . . . . . . . . . 30 10.8. sg-id. . . . . . . . . . . . . . . . . . . . . . . . . 30 10.9. modp. . . . . . . . . . . . . . . . . . . . . . . . . 30 10.10. result. . . . . . . . . . . . . . . . . . . . . . . . 30 10.11. feature . . . . . . . . . . . . . . . . . . . . . . . 32 10.12. features. . . . . . . . . . . . . . . . . . . . . . . 32 10.13. service . . . . . . . . . . . . . . . . . . . . . . . 32 10.14. services. . . . . . . . . . . . . . . . . . . . . . . 33 10.15. Dataflow Specializations. . . . . . . . . . . . . . . 33 11. Message Definitions . . . . . . . . . . . . . . . . . . . . . 33 11.1. Connection Start (CS) . . . . . . . . . . . . . . . . 34 11.2. Connection End (CE) . . . . . . . . . . . . . . . . . 35 11.3. Service Group Created (SGC) . . . . . . . . . . . . . 35 11.4. Service Group Destroyed (SGD) . . . . . . . . . . . . 36 11.5. Transaction Start (TS). . . . . . . . . . . . . . . . 36 11.6. Transaction End (TE). . . . . . . . . . . . . . . . . 36 11.7. Application Message Start (AMS) . . . . . . . . . . . 37 11.8. Application Message End (AME) . . . . . . . . . . . . 37 11.9. Data Use Mine (DUM) . . . . . . . . . . . . . . . . . 38 11.10. Data Use Yours (DUY). . . . . . . . . . . . . . . . . 39 11.11. Data Preservation Interest (DPI). . . . . . . . . . . 39 11.12. Want Stop Receiving Data (DWSR) . . . . . . . . . . . 40 11.13. Want Stop Sending Data (DWSS) . . . . . . . . . . . . 41 11.14. Stop Sending Data (DSS) . . . . . . . . . . . . . . . 41 11.15. Want Data Paused (DWP). . . . . . . . . . . . . . . . 42 Rousskov Standards Track [Page 2] RFC 4037 OPES Callout Protocol Core March 2005 11.16. Paused My Data (DPM). . . . . . . . . . . . . . . . . 43 11.17. Want More Data (DWM). . . . . . . . . . . . . . . . . 43 11.18. Negotiation Offer (NO). . . . . . . . . . . . . . . . 44 11.19. Negotiation Response (NR) . . . . . . . . . . . . . . 45 11.20. Ability Query (AQ). . . . . . . . . . . . . . . . . . 46 11.21. Ability Answer (AA) . . . . . . . . . . . . . . . . . 46 11.22. Progress Query (PQ) . . . . . . . . . . . . . . . . . 47 11.23. Progress Answer (PA). . . . . . . . . . . . . . . . . 47 11.24. Progress Report (PR). . . . . . . . . . . . . . . . . 48 12. IAB Considerations . . . . . . . . . . . . . . . . . . . . . 48 13. Security Considerations . . . . . . . . . . . . . . . . . . . 48 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 50 15. Compliance . . . . . . . . . . . . . . . . . . . . . . . . . 50 15.1. Extending OCP Core . . . . . . . . . . . . . . . . . . 51 A. Message Summary . . . . . . . . . . . . . . . . . . . . . . . 52 B. State Summary . . . . . . . . . . . . . . . . . . . . . . . 53 C. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 54 16. References . . . . . . . . . . . . . . . . . . . . . . . . . 54 16.1. Normative References . . . . . . . . . . . . . . . . . 54 16.2. Informative References . . . . . . . . . . . . . . . . 54 Author's Address. . . . . . . . . . . . . . . . . . . . . . . . . 55 Full Copyright Statement. . . . . . . . . . . . . . . . . . . . . 56 1. Introduction The Open Pluggable Edge Services (OPES) architecture [RFC3835] enables cooperative application services (OPES services) between a data provider, a data consumer, and zero or more OPES processors. The application services under consideration analyze and possibly transform application-level messages exchanged between the data provider and the data consumer. The OPES processor can delegate the responsibility of service execution by communicating with callout servers. As described in [RFC3836], an OPES processor invokes and communicates with services on a callout server by using an OPES callout protocol (OCP). This document specifies the core of that protocol ("OCP Core"). The OCP Core specification documents general application-independent protocol mechanisms. A separate series of documents describes application-specific aspects of OCP. For example, "HTTP Adaptation with OPES" [OPES-HTTP] describes, in part, how HTTP messages and HTTP meta-information can be communicated over OCP. Section 1.2 provides a brief overview of the entire OPES document collection, including documents describing OPES use cases and security threats. Rousskov Standards Track [Page 3] RFC 4037 OPES Callout Protocol Core March 2005 1.1. Scope The OCP Core specification documents the behavior of OCP agents and the requirements for OCP extensions. OCP Core does not contain requirements or mechanisms specific for application protocols being adapted. As an application proxy, the OPES processor proxies a single application protocol or converts from one application protocol to another. At the same time, OPES processor may be an OCP client, using OCP to facilitate adaptation of proxied messages at callout servers. It is therefore natural to assume that an OPES processor takes application messages being proxied, marshals them over OCP to callout servers, and then puts the adaptation results back on the wire. However, this assumption implies that OCP is applied directly to application messages that OPES processor is proxying, which may not be the case. OPES processor scope callout server scope +-----------------+ +-----------------+ | pre-processing | OCP scope | | | +- - - - - - - - - - - - - - - - - - -+ | | iteration | <== ( application data ) ==> | adaptation | | +- - - - - - - - - - - - - - - - - - -+ | | post-processing | | | +-----------------+ +-----------------+ An OPES processor may preprocess (or postprocess) proxied application messages before (or after) they are adapted at callout servers. For example, a processor may take an HTTP response being proxied and pass it as-is, along with metadata about the corresponding HTTP connection. Another processor may take an HTTP response, extract its body, and pass that body along with the content-encoding metadata. Moreover, to perform adaptation, the OPES processor may execute several callout services, iterating over several callout servers. Such preprocessing, postprocessing, and iterations make it impossible to rely on any specific relationship between application messages being proxied and application messages being sent to a callout service. Similarly, specific adaptation actions at the callout server are outside OCP Core scope. This specification does not define or require any specific relationship among application messages being proxied by an OPES processor and application messages being exchanged between an OPES processor and a callout server via OCP. The OPES processor usually provides some mapping among these application messages, but the processor's specific actions are beyond OCP scope. In other words, this specification is not concerned with the OPES processor role as Rousskov Standards Track [Page 4] RFC 4037 OPES Callout Protocol Core March 2005 an application proxy or as an iterator of callout services. The scope of OCP Core is communication between a single OPES processor and a single callout server. Furthermore, an OPES processor may choose which proxied application messages or information about them to send over OCP. All proxied messages on all proxied connections (if connections are defined for a given application protocol), everything on some connections, selected proxied messages, or nothing might be sent over OCP to callout servers. OPES processor and callout server state related to proxied protocols can be relayed over OCP as application message metadata. 1.2. OPES Document Map This document belongs to a large set of OPES specifications produced by the IETF OPES Working Group. Familiarity with the overall OPES approach and typical scenarios is often essential when one tries to comprehend isolated OPES documents. This section provides an index of OPES documents to assist the reader with finding "missing" information. o "OPES Use Cases and Deployment Scenarios" [RFC3752] describes a set of services and applications that are considered in scope for OPES and that have been used as a motivation and guidance in designing the OPES architecture. o The OPES architecture and common terminology are described in "An Architecture for Open Pluggable Edge Services (OPES)" [RFC3835]. o "Policy, Authorization, and Enforcement Requirements of OPES" [RFC3838] outlines requirements and assumptions on the policy framework, without specifying concrete authorization and enforcement methods. o "Security Threats and Risks for OPES" [RFC3837] provides OPES risk analysis, without recommending specific solutions. o "OPES Treatment of IAB Considerations" [RFC3914] addresses all architecture-level considerations expressed by the IETF Internet Architecture Board (IAB) when the OPES WG was chartered. o At the core of the OPES architecture are the OPES processor and the callout server, two network elements that communicate with each other via an OPES Callout Protocol (OCP). The requirements for this protocol are discussed in "Requirements for OPES Callout Protocols" [RFC3836]. Rousskov Standards Track [Page 5] RFC 4037 OPES Callout Protocol Core March 2005 o This document specifies an application agnostic protocol core to be used for the communication between an OPES processor and a callout server. o "OPES Entities and End Points Communications" [RFC3897] specifies generic tracing and bypass mechanisms for OPES. o The OCP Core and communications documents are independent from the application protocol being adapted by OPES entities. Their generic mechanisms have to be complemented by application-specific profiles. "HTTP Adaptation with OPES" [OPES-HTTP] is such an application profile for HTTP. It specifies how application-agnostic OPES mechanisms are to be used and augmented in order to support adaptation of HTTP messages. o Finally, "P: Message Processing Language" [OPES-RULES] defines a language for specifying what OPES adaptations (e.g., translation) must be applied to what application messages (e.g., e-mail from bob@example.com). P language is intended for configuring application proxies (OPES processors). 1.3. Terminology In this document, the keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. When used with the normative meanings, these keywords will be all uppercase. Occurrences of these words in lowercase constitute normal prose usage, with no normative implications. The OPES processor works with messages from application protocols and may relay information about those application messages to a callout server. OCP is also an application protocol. Thus, protocol elements such as "message", "connection", or "transaction" exist in OCP and other application protocols. In this specification, all references to elements from application protocols other than OCP are used with an explicit "application" qualifier. References without the "application" qualifier refer to OCP elements. OCP message: A basic unit of communication between an OPES processor and a callout server. The message is a sequence of octets formatted according to syntax rules (section 3.1). Message semantics is defined in section 11. application message: An entity defined by OPES processor and callout server negotiation. Usually, the negotiated definition would match the definition from an application protocol (e.g., [RFC2616] definition of an HTTP message). Rousskov Standards Track [Page 6] RFC 4037 OPES Callout Protocol Core March 2005 application message data: An opaque sequence of octets representing a complete or partial application message. OCP Core does not distinguish application message structures (if there are any). Application message data may be empty. data: Same as application message data. original: Referring to an application message flowing from the OPES processor to a callout server. adapted: Referring to an application message flowing from an OPES callout server to the OPES processor. adaptation: Any kind of access by a callout server, including modification, generation, and copying. For example, translating or logging an SMTP message is adaptation of that application message. agent: The actor for a given communication protocol. The OPES processor and callout server are OCP agents. An agent can be referred to as a sender or receiver, depending on its actions in a particular context. immediate: Performing the specified action before reacting to new incoming messages or sending any new messages unrelated to the specified action. OCP extension: A specification extending or adjusting this document for adaptation of an application protocol (a.k.a., application profile; e.g., [OPES-HTTP]), new OCP functionality (e.g., transport encryption and authentication), and/or new OCP Core version. 2. Overall Operation The OPES processor may use the OPES callout protocol (OCP) to communicate with callout servers. Adaptation using callout services is sometimes called "bump in the wire" architecture. 2.1. Initialization The OPES processor establishes transport connections with callout servers to exchange application messages with the callout server(s) by using OCP. After a transport-layer connection (usually TCP/IP) is established, communicating OCP agents exchange Connection Start (CS) messages. Next, OCP features can be negotiated between the processor and the callout server (see section 6). For example, OCP agents may negotiate transport encryption and application message definition. Rousskov Standards Track [Page 7] RFC 4037 OPES Callout Protocol Core March 2005 When enough settings are negotiated, OCP agents may start exchanging application messages. OCP Core provides negotiation and other mechanisms for agents to encrypt OCP connections and authenticate each other. OCP Core does not require OCP connection encryption or agent authentication. Application profiles and other OCP extensions may document and/or require these and other security mechanisms. OCP is expected to be used, in part, in closed environments where trust and privacy are established by means external to OCP. Implementations are expected to demand necessary security features via the OCP Core negotiation mechanism, depending on agent configuration and environment. 2.2. Original Dataflow When the OPES processor wants to adapt an application message, it sends a Transaction Start (TS) message to initiate an OCP transaction dedicated to that application message. The processor then sends an Application Message Start (AMS) message to prepare the callout server for application data that will follow. Once the application message scope is established, application data can be sent to the callout server by using Data Use Mine (DUM) and related OCP message(s). All of these messages correspond to the original dataflow. 2.3. Adapted Dataflow The callout server receives data and metadata sent by the OPES processor (original dataflow). The callout server analyses metadata and adapts data as it comes in. The server usually builds its version of metadata and responds to the OPES processor with an Application Message Start (AMS) message. Adapted application message data can be sent next, using Data Use Mine (DUM) OCP message(s). The application message is then announced to be "completed" or "closed" by using an Application Message End (AME) message. The transaction may be closed by using a Transaction End (TE) message, as well. All these messages correspond to adapted data flow. +---------------+ +-------+ | OPES | == (original data flow) ==> |callout| | processor | <== (adapted data flow) === |server | +---------------+ +-------+ The OPES processor receives the adapted application message sent by the callout server. Other OPES processor actions specific to the application message received are outside scope of this specification. Rousskov Standards Track [Page 8] RFC 4037 OPES Callout Protocol Core March 2005 2.4. Multiple Application Messages OCP Core specifies a transactions interface dedicated to exchanging a single original application message and a single adapted application message. Some application protocols may require multiple adapted versions for a single original application message or even multiple original messages to be exchanged as a part of a single OCP transaction. For example, a single original e-mail message may need to be transformed into several e-mail messages, with one custom message for each recipient. OCP extensions MAY document mechanisms for exchanging multiple original and/or multiple adapted application messages within a single OCP transaction. 2.5. Termination Either OCP agent can terminate application message delivery, transaction, or connection by sending an appropriate OCP message. Usually, the callout server terminates adapted application message delivery and the transaction. Premature and abnormal terminations at arbitrary times are supported. The termination message includes a result description. 2.6. Message Exchange Patterns In addition to messages carrying application data, OCP agents may also exchange messages related to their configuration, state, transport connections, application connections, etc. A callout server may remove itself from the application message processing loop. A single OPES processor can communicate with many callout servers and vice versa. Though many OCP exchange patterns do not follow a classic client-server model, it is possible to think of an OPES processor as an "OCP client" and of a callout server as an "OCP server". The OPES architecture document [RFC3835] describes configuration possibilities. The following informal rules illustrate relationships between connections, transactions, OCP messages, and application messages: o An OCP agent may communicate with multiple OCP agents. This is outside the scope of this specification. o An OPES processor may have multiple concurrent OCP connections to a callout server. Communication over multiple OCP connections is outside the scope of this specification. Rousskov Standards Track [Page 9] RFC 4037 OPES Callout Protocol Core March 2005 4. Data center interconnect As shown in Fig.1, we employ the cascaded MEMS-switches. The inter- cluster MEMS in the core is in charge of the communication between ToRs in different clusters. Multiple SFPs and SCFDM transceivers are implemented to realize the mixed transmission whose bandwidth demand is either fixed grid or flexible grid. To provide flexible switching functionality, we proposed the module named Mux/Demux & SSS which is illustrated in Fig.2. Optical components such as coupler, Spectrum Selective Switches (SSS), Arrayed Waveguide Grating (AWG), and circulator are attached to a backplane to further increase the flexibility of coping with different traffic demands. In Fig.2, the symbol "@" represents a circulator which is a passive non-reciprocal three-port device, and an optical signal entering any port is transmitted to the next port in rotation(only). The coupler is a passive device which is used to split and combine signals in the optical network and can have multiple inputs and outputs. The SSS is typical an 1xN optical component that can partition the spectrum of input signal to different ports. The AWG is a passive data-rate independent optical device that route each wavelength of an input to a different output. Using this module, traffic can be deliberately added and dropped through these components, and can be merged and switched to the same destination together through AWG or coupler, and also can be separated by SSS and switched to the different output ports for purpose of realizing Multi-Input Multi-Output(MIMO) switching. At the same time, each ToR has both SFP and SCFDM transceivers which can realize fixed or flexible grid traffic switching. Thus, each rack can communicate with multiple racks simultaneous and high interconnect efficiency can be achieved as arbitrary traffic inter or intra ToRs can be switched using fine bandwidth rather than fixed grid bandwidth. +----------------+ +----------------+ +----------------+ |Mux/Demux &SSS 1| |Mux/Demux &SSS 2| |Mux/Demux &SSS 3| ... +----------------+ +----------------+ +----------------+ | | | | | | | | | | | | | | | | | | +----------------------------------------------------------------+ | Optical OXC | +----------------------------------------------------------------+ | | | | | | | | | | | | +--------------+ +--------------+ +--------------+ | SFP|BV-TX/RX | | SFP|BV-TX/RX | | SFP|BV-TX/RX | | ToR 1 | | ToR 2 | | ToR 3 | +--------------+ +--------------+ +--------------+ Kong, et al. Expires October 08, 2018 [Page 5] Internet-Draft Routing Optimization with SDN in DC Networks April 2018 Figure 1: Schematic of architecture in data center +------------------------------------------------------------------+ | | +------------------------------------------------------------------+ A A A A | | | | +---|---------------------|--------|------|--------|--|--|-----|--+ | | V | | | | | | | | | +--------------@ V | +---------+ | | | | | +----------A--------@ V | AWG | | | | | | | +-----|---------A------@ +---------+ | | | | | | | | | A | | | | | V V V | | | +--------+ | | | +---------+ +---------------------+ | | +-----| Coupler | | SSS | | | +---------+ +---------------------+ | +-----------------------------------------------------------------+ Figure 2: Mux/Demux &&& SSS 5. Traffic-Monitor based routing in data center networks The proposed architecture which is based on SDN technology is shown in Fig.3. Resource Computation Element (RCE) is responsible for allocating available port resource to configure the backplane to sever the new coming request based on the resource information provided by the Resource Management Element (RME).RME storages all of the port and spectrum information. Both RCE and RME are controlled by a SDN controller. In particular, RCE can be implemented with certain algorithm for routing and allocating spectrum optimally and RME can also be configured by the SDN controller. When a new traffic comes from ToRs, RCE inquiries the RME for the available port resource and other information to compute the most suitable route and allocate appropriate spectrum. If there is no available resource for the moment, the request will be stored in the buffer. The traffic monitor provides all the traffic request information both come and in the buffer in order to evaluate the type of the traffic, and then passes the information to RME to execute the processing scheme which we will discuss about later. Kong, et al. Expires October 08, 2018 [Page 6] Internet-Draft Routing Optimization with SDN in DC Networks April 2018 After finishing computing the optimized route, the optical switching module is configured through an agent to allocate appropriate bandwidth for the request. With the implement of bandwidth variable component and the capacity of both fixed and flexible grid switching, the optical backplane can be ordered to allocate exactly appropriate bandwidth for coming demands. As a consequence, the requests from the ToRs are satisfied with the optimized route and high resource utilizing. +---------------------------------|-----------+ ---+---+---+ | SDN controller | +---> | | |----+-->+--------------+ +--------------+ | | ---+---+---+ | | Resource |----->| Resource | | | Buffer | | Computation | | Management | | | ---+---+---+ | | Element |<-----| Element | | | +-> | | |----+-->+--------------+ +--------------+ | | | ---+---+---+ +----------A----------------------------------+ | | | | | | | v | | +--------------------+------+ | | +---------+ +----+ +-----+ | Agent| | +--| Request |---->|ToRs|---->|Tx/Rx|-----> +------+------+------+ | +---------+ +----+ +-----+ | Optical | | +---------+ +----+ +-----+ | Switching | +----| Request |---->|ToRs|---->|Tx/Rx|-----> | Module | +---------+ +----+ +-----+ +--------------------+ +------------+ A | Traffic | | | Monitor |----+ +------------+ Figure 3: Traffic Monitor implemented architecture 6. Dynamic traffic demand recognition scheme With the implement of traffic monitor, the proposed architecture can support the new switching requirements by executing dynamic traffic demand recognition scheme through RME which is described above. We monitor the traffic before they come, and evaluate the type of traffic demand, and then allocate appropriate bandwidth according to the request. When traffic comes, it is arbitrated by RME whether it is a flexible grid signal to determine where it goes. A flexible grid signal is transferred to the SCFDM transceiver and then arbitrated whether it is intra-data center request. If it is, optical components such as SSS and coupler will be placed to set or reuse connection. Similarly, a fixed grid signal is transferred to SFP module and arbitrated whether it is intra-cluster request to determine where it Kong, et al. Expires October 08, 2018 [Page 7] Internet-Draft Routing Optimization with SDN in DC Networks April 2018 will be transferred next step. Thus, bandwidth with fine granularity can be allocated to satisfy the dynamic traffic demand in data center network. For instance, mice flow can be served directly by being modulated to SCFDM transmitter. At the meantime, elephant flow can also be divided into fixed and flexible grid signal. Fixed grid signal can be switched to the WDM SFP transceivers which support 2.5 Gbps and 10 Gbps transmission. Flexible grid traffic demand can be served by the SCFDM transceivers. Such algorithm can allocate optimized bandwidth to potential request. Thus, both mice and elephant flow can be served by either using the already existing connection or setup new route to avoid frequent configuration of the optical backplane. 7. Security Considerations Security in the communication between ToRs through Optical Backplane in data center network is to be addressed. While the security of the architecture described in this document greatly depends on the security of communication mechanism itself such as communication protocols, processing procedure and so on. However, the architecture that implements the traffic monitor can improve the security of switching in data center network by evaluating the type of coming traffic. 8. IANA Considerations This document includes no request to IANA. 9. Conclusions and Use Cases Data centers have received more and more attention as a result of increasing demand for storing and switching large volumes of data. With the advantage of open programmatic interface and privacy of operations, SDN tends to be applied to data center so as to improve the spectrum efficiency and bandwidth utilizing. This document describes an architecture where a traffic monitor is implemented and bandwidth variable components are adopted. Due to the capacity of monitoring the traffic before they come, we can evaluate the type of the requests and inquires RME whose function is to store all ports information whether they are occupied or released. Based on obtained the available resource information from RME, RCE then allocate appropriate bandwidth for the request which may be fixed or flexible grid. Rather than allocating the bandwidth with rigid and coarse granularity, the new switching requirements are supported to satisfy the dynamic traffic demand in data center networks. As a Kong, et al. Expires October 08, 2018 [Page 8] Internet-Draft Routing Optimization with SDN in DC Networks April 2018 consequence, the spectrum efficiency is optimized and bandwidth utilization is increased dramatically. With the feature of switching traffic using both fixed and flexible grid bandwidth, the proposed architecture can be well adopted in various network structure especially in data center network. For example, it can be accustomed to the scenario where data flow is big and duration time is long such as data migration in the midnight, as well as the scenario where data flow is slight and duration time is short such as a Web request. 10. References 10.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 10.2. Informative References [KT12] C. Kachris, and I. Tomkos, "A Survey on Optical Interconnects for Data Centers," 2012. Kong, et al. Expires October 08, 2018 [Page 9] Internet-Draft Routing Optimization with SDN in DC Networks April 2018 Authors' Addresses Qian Kong Beijing University of Posts and Telecommunications Email: kongqian@bupt.edu.cn Tao Gao Beijing University of Posts and Telecommunications Email: taogao@bupt.edu.cn Dajiang Wang ZTE Corporation Email: wang.dajiang@zte.com.cn Zhenyu Wang ZTE Corporation Email: wang.zhenyu1@zte.com.cn Jiayu Wang ZTE Corporation Email: wang.jiayu1@zte.com.cn Bingli Guo Beijing University of Posts and Telecommunications Email: guobingli@bupt.edu.cn Shanguo Huang Beijing University of Posts and Telecommunications Email: shghuang@bupt.edu.cn Kong, et al. Expires October 08, 2018 [Page 10]