Network Working Group Fangwei Hu Internet-Draft Qiandeng Liang Intended status: Standards Track Jianjie You Expires: March 15, 2014 ZTE Corporation September 11, 2013 network service chaining metadata draft-hu-nsc-metadata-00.txt Abstract This draft provides a programmable NSC metadata that could be carried by different transport types to create network service paths. The NSC metadata architecture and metadata format are defined in this document. In addition, the NSC metadata format negotiation mechanism between network controller node and network forwarding nodes is specified. Status of This Memo 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 March 15, 2014. Copyright Notice 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 Hu, et al. Expires March 15, 2014 [Page 1] Internet-Draft nsc metadata September 2013 the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2 3. Network Service Chaining Metadata Component Structure . . . . 3 4. Network Service Chaining Metadata Format . . . . . . . . . . 4 5. Network Service Chaining Metadata Generation . . . . . . . . 5 6. Metadata Format Negotiation . . . . . . . . . . . . . . . . . 5 7. Benefits of NSC Metadata . . . . . . . . . . . . . . . . . . 5 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 8.1. Security Considerations . . . . . . . . . . . . . . . . . 6 8.2. Acknowledgements . . . . . . . . . . . . . . . . . . . . 6 9. Normative References . . . . . . . . . . . . . . . . . . . . 6 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 1. Introduction Network services are widely deployed and essential in new data center network and cloud architecture, which requires more flexible network service deployment models. The network services provide many functions: such as NAT, Firework, and server load balancing. This document provides a network service based forwarding by metadata passing information between the network forwarding nodes (NFN). The packet is handled in a network forwarding node (NFN), and the forwarding parameters for that packet is encapsulated as metadata format and then inserted into the packet to form a service forwarding path, then the packet is passed to next network forwarding node. This mechanism improves the forwarding efficiency and flexibility by using the information from the previous NFN. In addition, a procedure to negotiate the metadata format is provided in this document. 2. Terminology Network Forwarding Node: NFN,is a programmable Router/Switch, or even a logical switch device. Network Controller Node: NCN.It interacts with NFN. The NCN negotiates the NSC metadata format with the NFNs. Network service chaining: NSC, a service chain defines the services path required. Hu, et al. Expires March 15, 2014 [Page 2] Internet-Draft nsc metadata September 2013 Metadata:a register value that is used to pass information from one NFN to the other. 3. Network Service Chaining Metadata Component Structure Figure 1 is the metadata NSC component architecture. Consider three NFNs in the NSC network, NFN A, NFN B and NFN C. NFN A and NFN B support the same metadata format, i.e. metadata1. NFN B and NFN C support another metadata format i.e.metadata 2. The edge network forwarding node (NFN A) receives the packets from the traditional networks, and inserts the metadata to the packet based on the metadata 1 format. The packets including metadata 1 are transferred from NFN A to NFN B via a tunnel protocol specified by metadata 1. After receiving the packets from NFN A, NFN B parses the packets according to the definition of metadata 1. This metadata is transparent to any other NFNs between NFN A and NFN B as they cannot be aware of metadata 1. Similarly, the packets including metadata 2 are transferred from NFN B to NFN C via a tunnel protocol specified by metadata 2. +----------------+ | application | +-------+--------+ | | +----------------+ | NCN | +----------------+ / \ *************/***************\************* * / NSC Network \ * * +------+ +------+ +------+ * -------*----| NFN A|----| NFN B|----| NFN C|-----*------ ^ * +------+ ^ +------+ ^+------+ * | ***************|************|*************** +---------------+ | | |Link Header|PDU| | | +---------------+ | | +-------------------------+ | |Link Header|metadata1|PDU| | +-------------------------+ | +-------------------------+ |Link Header|metadata2|PDU| +-------------------------+ Hu, et al. Expires March 15, 2014 [Page 3] Internet-Draft nsc metadata September 2013 Figure 1 NSC metadata architecture 4. Network Service Chaining Metadata Format Metadata format is defined as Figure 2. The metadata contains following fields: Transport type: is the corresponding value for the transport link that metadata would be carried (e.g. Ethertype, protocol number, UDP destination port). Metadata could be carried by different transport links. If it is carried by Ethernet link, the metadata is encapsulated as the payload of Ethernet frame, and the transport type is an Ethernet type/Length value (e.g. 0xa811, TBD). If it is carried by IP network, the transport type is a protocol number. If it is carried in UDP message, the metadata is in the UDP PDU message, and the corresponding transport type is UDP destination port. Reserved: is reserved for future use. Format ID: represents ID of this metadata format. The format ID is unique to identify a metadata format. There are 256 types of metadata format for maximum. Length: indicates the total length of the metadata. Service attribute: represents the attribute of the service for the metadata. It could be a flow-id of the traffic, or dpi-id for the DPI service. If the packets carrying metadata are transferred via Ethernet type , the Ethertype would be replaced as 0xyyyy (e.g. 0xa811), and the original Ethertype could be stored as one of the service attribute of the metadata. When the next NFN receives the packets, it decapsulates the packets and retrieves the original Ethertype according to the value carried in the metadata. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-----------------------------+-------------------------------+ | Transport type | Reserved | +-------------+---------------+-------------------------------+ | Format ID | Length | Service attribute1 | +-----------------------------+-------------------------------+ | Service attribute 1 | Service attribute2 | +-----------------------------+-------------------------------+ | Service attribute 2 | ...... | +-----------------------------+-------------------------------+ Hu, et al. Expires March 15, 2014 [Page 4] Internet-Draft nsc metadata September 2013 Figure 2 Metadata format 5. Network Service Chaining Metadata Generation The NCN could request NFN to encapsulate the metadata or not. If the metadata needs to be encapsulated in the packet, the NCN would indicate the NFN how to generate and encapsulate the metadata. The NCN could send the metadata generation message to the NFN, including the transport type, generation parameters. For the source of the metadata content could be generated by the following methods: o FIX: the value is determined by the NCN. o PACKET: the value comes from the packet, and the field is specified by the NCN. o LOCAL: the value is generated locally. For example, it is a 32bits random value, or 64bits time stamp. o METADATA: the value comes from the metadata from the previous NFN. 6. Metadata Format Negotiation Metadata is configured locally in a network forwarding node by CLI, SNMP. Each network forwarding nodes could support several metadata formats (metadata format list). The network forwarding node reports its metadata format list to the network controller node via a protocol, which could be the extension of the existing protocol, such as I2RS protocol ([I2RS]), or some other new protocol. When NCN computes the service path based on the service requirements, it sends the metadata format or rules to the NFNs corresponding to a specific service path, to indicate those NFN's metadata encapsulation methods for their next NFNs. 7. Benefits of NSC Metadata The network service chaining metadata can provides the following benefits: (1) Providing service chaining path: The data plane forwarding parameters for a service could be added to service attribute fields of metadata. The service is usually classified, and formed the forwarding parameters, which are encapsulated as metadata format at the edge network forwarding node. The other NFNs supporting the same metadata format can use the forwarding parameters for service forwarding when receive the packets with that metadata encapsulation. Hu, et al. Expires March 15, 2014 [Page 5] Internet-Draft nsc metadata September 2013 (2) Programmability and flexibility: the metadata format is negotiated among NFNs, and can be programmable through NCN. The NFN can support 256 types of metadata at most, which can satisfy the current service requirements In addition, the metadata can be carried at multiple transport networks (e.g. Ethernet, IP, and UDP). (3) Compatibility: the packet with metadata encapsulation is transparent to any other NFNs which do not support metadata format. This solution does not bring any compatibility issues for the current networks. 8. IANA Considerations IANA is requested to allocate a protocol number (xx) if transport type is IP network, and a port number (xxxx) if UDP message. 8.1. Security Considerations TBD 8.2. Acknowledgements TBD 9. Normative References [I2RS] Atlas, A., Nadeau, T., and D. Ward, "Interface to the Routing System Framework", draft-ward-i2rs-framework-01 (work in process), July 2012. [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, June 1999. Authors' Addresses Fangwei Hu ZTE Corporation No.889 Bibo Rd Shanghai 201203 China Phone: +86 21 68896273 Email: hu.fangwei@zte.com.cn Hu, et al. Expires March 15, 2014 [Page 6] Internet-Draft nsc metadata September 2013 Qiandeng Liang ZTE Corporation No.68 Zijinhua Rd Nanjing, Jiangsu 210012 China Email: Liang.Qiandeng@zte.com.cn Jianjie You ZTE Corporation No.50 Ruanjian Avenue Nanjing, Jiangsu 210012 China Phone: +86 25 88014962 Email: You.Jianjie@zte.com.cn Hu, et al. Expires March 15, 2014 [Page 7]