Internet DRAFT - draft-hu-nsc-metadata
draft-hu-nsc-metadata
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]
