Internet DRAFT - draft-wang-sfc-md-type-issues
draft-wang-sfc-md-type-issues
SFC WG C. Wang
Internet-Draft W. Meng
Intended status: Standards Track ZTE Corporation
Expires: April 27, 2017 October 24, 2016
Metadata Type Issues
draft-wang-sfc-md-type-issues-02
Abstract
Service function chain is the definition of an ordered set of service
functions. After instantiated, the service function path is created
and the classified traffic is steered through the corresponding
service function path and then forwarded to the final destination.
Metadata (MD) is conveyed in SFC data plane which provides the
ability to exchange context information between classifiers and SFs,
among SFs, and between external systems and SFs. This document is
motivated to state an issue when MD Type = 0x1.
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 April 27, 2017.
Copyright Notice
Copyright (c) 2016 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
Wang & Meng Expires April 27, 2017 [Page 1]
Internet-Draft Metadata Type Issues October 2016
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.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Convention and Terminology . . . . . . . . . . . . . . . . . 3
3. An issue in MD-Type = 0x1 . . . . . . . . . . . . . . . . . . 4
4. An analysis on how to solve above issue . . . . . . . . . . . 6
4.1. Method 1 . . . . . . . . . . . . . . . . . . . . . . . . 6
4.2. Method 2 . . . . . . . . . . . . . . . . . . . . . . . . 7
5. Gap analysis . . . . . . . . . . . . . . . . . . . . . . . . 8
6. Security Considerations . . . . . . . . . . . . . . . . . . . 8
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
8.1. Normative References . . . . . . . . . . . . . . . . . . 8
8.2. Informative References . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9
1. Introduction
Service function chain is the definition of an ordered set of service
functions. After instantiated, the service function path is created
and the classified traffic is steered through the corresponding
service function path and then forwarded to the final destination.
Metadata is conveyed in the Context Headers in SFC data plane which
provides the ability to exchange context information between
classifiers and SFs, among SFs, and between external systems and SFs.
In [I-D.ietf-sfc-nsh], it defines two mandate parts including Base
Header and Service Path Header in NSH header. Besides these two
parts, there are Contexts Headers immediately following the Service
Path Header as well. As for what kinds of Contexts Headers is
according to the MD Type specified in the Base Header. In fact, it
defines two MD types:
When the Base Header specifies MD Type = 0x1, four Mandatory Context
Headers must be added immediately following the Service Path Header,
as per Figure 1.
Wang & Meng Expires April 27, 2017 [Page 2]
Internet-Draft Metadata Type Issues October 2016
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Ver|O|C|R|R|R|R|R|R| Length | MD-type=0x1 | Next Protocol |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Service Path ID | Service Index |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mandatory Context Header |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mandatory Context Header |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mandatory Context Header |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mandatory Context Header |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: NSH Format when MD Type = 0x1
When the Base Header specifies MD Type = 0x2, zero or more Variable
Length Context Headers MAY be added immediately following the Service
Path Header, as per Figure 2.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Ver|O|C|R|R|R|R|R|R| Length | MD-type=0x2 | Next Protocol |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Service Path ID | Service Index |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Variable Length Context Headers (opt.) ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: NSH Format when MD Type = 0x2
From the perspective in [I-D.ietf-sfc-nsh] and its companion drafts,
it seems to be apt to support MD Type = 0x1 to be mandate.
This document is motivated to state an issue when MD Type = 0x1 is
mandate and discuss which Metadata Type in more appropriate in what
circumstances in SFC data plane.
2. Convention and Terminology
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 [RFC2119].
Wang & Meng Expires April 27, 2017 [Page 3]
Internet-Draft Metadata Type Issues October 2016
The terms are all defined in [RFC7665] and [I-D.ietf-sfc-nsh].
3. An issue in MD-Type = 0x1
In [I-D.guichard-sfc-nsh-dc-allocation], it provides the allocation
scheme when Network Service Header (NSH) is used under data center
scenario and defines a recommended default allocation for the
Mandatory Context Headers while MD-Type = 0x1 (See Figure 3 below).
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Ver|O|C|R|R|R|R|R|R| Length | MD-type=0x1 | Next Protocol |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Service Path ID | Service Index |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|D|F|Res| Source Node ID | Source Interface ID | Context Header 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Tenant ID | Context Header 2
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Class / Reserved | Source Class | Context Header 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ServiceTag / Opaque Service Class | Context Header 4
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: NSH DC Context Allocation
What's more, in [I-D.napper-sfc-nsh-mobility-allocation] , it
provides the allocation scheme when Network Service Header (NSH) is
used under mobility scenario and defines a recommended default
allocation for the Mandatory Context Headers while MD-Type = 0x1 (See
Figure 4 below).
Wang & Meng Expires April 27, 2017 [Page 4]
Internet-Draft Metadata Type Issues October 2016
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Ver|O|C|R|R|R|R|R|R| Length | MD-type=0x1 | Next Protocol |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Service Path ID | Service Index |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flow Cookie | Context Header 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserv |TenTy| Tenant ID | Context Header 2
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sub/App ID ~ Context Header 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Sub/App ID (cont.) | Context Header 4
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: NSH Mobility Context Header
There is no issue while the data center scenario and mobility
scenario are deployed separately. For example, SFs in data centers
can identify the exactly meaning in the Mandatory Context Headers
according to the definition in [I-D.guichard-sfc-nsh-dc-allocation],
while SFs in mobility service provider can understand the exactly
meaning in the Mandatory Context Headers according to the definition
in [I-D.napper-sfc-nsh-mobility-allocation].
But it is possible that there is a mixed need, such as Data Centers
providing both wireless and classic DC services. Under this mixed
scenario, there seems to be some difficulty when SFs tries to analyze
the Mandatory Context Headers while MD Type = 0x1.
For example, in Figure 5, it illustrates the mixed scenario where a
data center provides both wireless and classic DC services. And in
this data center, a service function (such as SF3) serves both
wireless and classic DC services.
Wang & Meng Expires April 27, 2017 [Page 5]
Internet-Draft Metadata Type Issues October 2016
.--.--.--.--.--.--.--.--.--.--.--.--.--.--.--.--.--.--.
( DC serving both wireless and classic DC services )
( )
Claasic DC incoming traffic( +-----+ +-----+ +-----+ )
------->-------------> ---(---> | SF1 |----->| SF2 |------>\ /--->-- | SF4 |----->----)----->
( +-----+ +-----+ \ / +-----+ )
( +--|--+ )
( | SF3 | )
( +--|--+ )
Wireless incoming traffic( +-----+ +-----+ / \ +-----+ )
-------> ------------> ---(---->| SF5 |----->| SF6 |------>/ \--->-- | SF7 |----->----)----->
( +-----+ +-----+ +-----+ )
( )
.--.--.--.--.--.--.--.--.--.--.--.--.--.--.--.--.--.--.
Figure 5: DC serving both wireless and classic DC services
When traffic is steered to SF3, how SF3 to correctly analyze the
Mandatory Context Headers in NSH within the arriving traffic? In
other words, how SF3 in this mixed environments to know the receiving
Mandatory Context Headers in the NSH are used for wireless service or
classic DC services?
4. An analysis on how to solve above issue
There may be several methods to address the above issue. Here just
tries to list two feasible methods.
4.1. Method 1
Still using the recommended definition in draft-dc and draft-mobility
while MD Type = 0x1, but tries to add some bits in NSH to identify
what type of Mandatory Context Headers is conveyed within NSH. For
example, as per Figure 6, here occupies the lowest two bits in MD
Type field to identify the exact type of Mandatory Context Headers.
Wang & Meng Expires April 27, 2017 [Page 6]
Internet-Draft Metadata Type Issues October 2016
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Ver|O|C|R|R|R|R|R|R| Length |MD-type=0x1| T | Next Protocol |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Service Path ID | Service Index |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mandatory Context Header |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mandatory Context Header |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mandatory Context Header |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mandatory Context Header |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: Two bits in MD Type field
In fact, this issue only exists while MD Type = 0x1. While MD Type =
0x2, there is no such issue. So these added two bits have no meaning
while MD Type = 0x2.
When traffic is steered to SF3, SF3 finds the MD Type = 0x1 and then
analyze these added two bits to know what kind of Mandatory Context
Headers is contained. After that, correctly analyze the following
Mandatory Context Headers according to the type.
4.2. Method 2
It also may be a feasible method to use MD Type = 0x2 to identify the
Context Headers. According to MD Type = 0x2, the exact format for
Variable Length Context Headers is illustrated in Figure 7, which
states the TLV Class field or Type field already. Then, no matter in
separated scenarios or mixed scenarios, there is no confusion when
traffic arrives at SFs.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TLV Class |C| Type |R|R|R| Len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Variable Metadata |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: Variable Length Context Headers when MD Type = 0x2
Wang & Meng Expires April 27, 2017 [Page 7]
Internet-Draft Metadata Type Issues October 2016
5. Gap analysis
This document tries to raise one issue when using MD Type = 0x1 as
mandatory type. As for which MD Type need to be mandatory there
still need much more attentions and discussions.
6. Security Considerations
TBD
7. IANA Considerations
TBD
8. References
8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
[RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function
Chaining (SFC) Architecture", RFC 7665,
DOI 10.17487/RFC7665, October 2015,
<http://www.rfc-editor.org/info/rfc7665>.
8.2. Informative References
[I-D.guichard-sfc-nsh-dc-allocation]
Guichard, J., Smith, M., Surendra, S., Majee, S., Agarwal,
P., Glavin, K., and Y. Laribi, "Network Service Header
(NSH) Context Header Allocation (Data Center)", draft-
guichard-sfc-nsh-dc-allocation-05 (work in progress),
August 2016.
[I-D.ietf-sfc-nsh]
Quinn, P. and U. Elzur, "Network Service Header", draft-
ietf-sfc-nsh-10 (work in progress), September 2016.
[I-D.napper-sfc-nsh-mobility-allocation]
Napper, J., Surendra, S., Muley, P., and W. Henderickx,
"NSH Context Header Allocation -- Mobility", draft-napper-
sfc-nsh-mobility-allocation-02 (work in progress),
November 2015.
Wang & Meng Expires April 27, 2017 [Page 8]
Internet-Draft Metadata Type Issues October 2016
Authors' Addresses
Cui Wang
ZTE Corporation
No.50 Software Avenue, Yuhuatai District
Nanjing
China
Email: wang.cui1@zte.com.cn
Wei Meng
ZTE Corporation
No.50 Software Avenue, Yuhuatai District
Nanjing
China
Email: meng.wei2@zte.com.cn,vally.meng@gmail.com
Wang & Meng Expires April 27, 2017 [Page 9]
