One document matched: draft-napper-sfc-nsh-mobility-allocation-01.xml
<?xml version='1.0' ?>
<!DOCTYPE rfc SYSTEM 'rfc2629.dtd' [
<!ENTITY rfc2119 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml'>
<!ENTITY rfc7498 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.7498.xml'>
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- used by XSLT processors -->
<!-- For a complete list and description of processing instructions (PIs),
please see http://xml.resource.org/authoring/README.html. -->
<!-- Below are generally applicable Processing Instructions (PIs) that most I-Ds might want to use.
(Here they are set differently than their defaults in xml2rfc v1.32) -->
<?rfc strict="yes" ?>
<!-- give errors regarding ID-nits and DTD validation -->
<!-- control the table of contents (ToC) -->
<?rfc toc="yes"?>
<!-- generate a ToC -->
<?rfc tocdepth="3"?>
<!-- the number of levels of subsections in ToC. default: 3 -->
<!-- control references -->
<?rfc symrefs="yes"?>
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="yes" ?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space
(using these PIs as follows is recommended by the RFC Editor) -->
<?rfc compact="yes" ?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="no" ?>
<!-- keep one blank line between list items -->
<!-- end of list of popular I-D processing instructions -->
<rfc category="info" ipr='trust200902' docName='draft-napper-sfc-nsh-mobility-allocation-01'>
<front>
<title abbrev='NSH Mobility Context Allocation'>NSH Context Header Allocation -- Mobility</title>
<author initials='J.' surname='Napper'
fullname='Jeffrey Napper'>
<organization>Cisco Systems, Inc.</organization>
<address>
<email>jenapper@cisco.com</email>
</address>
</author>
<author initials='S.' surname='Kumar'
fullname='Surendra Kumar'>
<organization>Cisco Systems, Inc.</organization>
<address>
<email>smkumar@cisco.com</email>
</address>
</author>
<date day='16' month='May' year='2015' />
<area>Routing</area>
<workgroup>Service Function Chaining</workgroup>
<keyword>Internet-Draft</keyword>
<abstract>
<t>This document provides a recommended allocation of the mandatory
fixed context headers for a Network Service Header (NSH) within the
mobility service provider network context. NSH is described in detail
in <xref target='ietf-sfc-nsh' />. This allocation is intended to
support uses cases as defined in <xref target='ietf-sfc-use-case-mobility' />.</t>
</abstract>
<note title='Requirements Language'>
<t>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
<xref target='RFC2119' />.</t>
</note>
</front>
<middle>
<section anchor='sec_intro' title='Introduction'>
<t>Service function chaining provides a mechanism for network traffic to be forced through multiple service functions in a sequence. Metadata can be useful to service functions. Network Service Headers (NSH) povides support for carrying shared metadata between service functions (and devices) using 4 fixed-length 32-bit context headers as defined in <xref target='ietf-sfc-nsh' />. NSH is then encapsulated within an outer header for transport.</t>
<t>This document provides a recommended default allocation scheme for the fixed-length context headers in the context of service chaining within mobile service provider networks. Supporting use cases describing the need for a metadata header in this context are described in <xref target='ietf-sfc-use-case-mobility' />. This draft does not address control plane mechanisms.</t>
</section>
<section anchor='sec_language' title='Definition Of Terms'>
<t>This document uses the terms as defined in
<xref target='RFC7498' /> and <xref target='ietf-sfc-arch' />.</t>
</section>
<section anchor='sec_nsh' title='Network Service Header (NSH) Context Headers'>
<t>In Service Function Chaining, the Network Service Header is composed of a 4-byte base header (BH1), a 4-byte service path header (SH1) and four mandatory 4-byte context headers (CH1-CH4) as described in <xref target='ietf-sfc-nsh' />.</t>
<figure anchor='fig_nsh_header' title='Network Service Header - MD Type 0x01'>
<artwork>
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 = 0x01| Next Protocol | BH1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Service Path ID | Service Index | SH1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mandatory Context Header 1 | CH1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mandatory Context Header 2 | CH2
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mandatory Context Header 3 | CH3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mandatory Context Header 4 | CH4
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
</figure>
</section>
<section anchor='sec_mobility_alloc' title='Recommended Mobility Context Allocation'>
<t>The following context header allocation provides information to support service function chaining in a mobile service provider network as described in <xref target='ietf-sfc-use-case-mobility' />.</t>
<t>The set of context headers can be delivered to service functions that can use the metadata within to enforce policy, communicate between service functions, provide subscriber information and other functionality. Several of the context headers are typed allowing for different metadata to be provided to different service functions or even to the same service function but on different packets within a flow. Which metadata are sent to which service functions is decided in the SFC control plane and is thus out of the scope of this document.</t>
<figure anchor='fig_mobility_context' title='NSH Mobility Context Allocation'>
<artwork>
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flow Cookie | CH1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserv |TenTy| Tenant ID | CH2
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sub/App ID ~ CH3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Sub/App ID (cont.) | CH4
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
</figure>
</section>
<section anchor='sec_mobility_spec' title='Mobility Allocation Specifics'>
<t>The intended use for each of the context header allocations is as
follows:
<list style='hanging'>
<t hangText="Flow Cookie"> - unique value with respect to the Subscriber/
Application Identifier field that can be used to identify a packet
or flow even if the encapsulated packet changes (e.g., when a flow
is terminated at a proxy).</t>
<t hangText="Reserv"> - Reserved.</t>
<t hangText="TenTy"> - Tenant Type represents type of Tenant Identifier field
(e.g., vlan, vxlan, vrf, mpls, etc.).</t>
<t hangText="Tenant ID"> - value encoded according to Tenant Type field
corresponding to encapsulated packet (e.g., ingress VRF id). The
Tenant ID field allows the Base Header (BH1) and Service Headers
(SH) to be tenant independent.</t>
<t hangText="Sub/App ID"> - 64-bit length Subscriber/Application identifier (e.g.,
IMSI [itu-e-164], MSISDN (8-15 digit) [itu-e-164], or
implementation-specific Application ID) of the corresponding
subscriber/application for the flow.</t>
</list>
</t>
</section>
<section anchor='sec_context' title='Context Allocation and Control Plane Considerations'>
<t>This document describes an allocation scheme for the mandatory context
headers in the context of mobile service providers. This suggested allocation
of context headers should be considered as a guideline and may vary depending
on the use case. The control plane aspects
of specifying and distributing the allocation scheme among different service
functions within the Service Function Chaining environment to guarantee consistent
semantics for the metadata is beyond the scope of this document.</t>
</section>
<section title='Security Considerations'>
<t>The context header allocation recommended by this document includes numbers
that must be distributed consistently across a Service Function Chaining environment.
Protocols for distributing these numbers securely are required in the control plane,
but are out of scope of this document.</t>
<t>Furthermore, some of the metadata carried in the context headers require secure
methods to prevent spoofing or modification by service function elements that may
themselves be exposed to subscriber traffic and thus might be compromised. This
document does not address such security concerns.</t>
</section>
<section title='IANA Considerations'>
<t>This document has no actions for IANA.</t>
</section>
<section title='Acknowledgments'>
<t>The authors would like to thank Jim Guichard for his assistance
structuring the document.</t>
</section>
</middle>
<back>
<references title='Normative References'>
&rfc2119;
</references>
<references title='Informative References'>
&rfc7498;
<reference anchor='ietf-sfc-use-case-mobility'>
<front>
<title>Service Function Chaining Use Cases in Mobile Networks</title>
<author initials='W.' surname='Haeffner'/>
<author initials='J.' surname='Napper'/>
<author initials='M.' surname='Stiemerling'/>
<author initials='D. R.' surname='Lopez'/>
<author initials='J.' surname='Uttaro'/>
<date month='January' year='2015' />
</front>
<seriesInfo name='I-D' value='draft-ietf-sfc-use-case-mobility-03 (work in progress)' />
</reference>
<reference anchor='ietf-sfc-nsh'>
<front>
<title>Network Service Header</title>
<author surname='Quinn' initials='P.'/>
<author surname='Elzur' initials='U.'/>
<date month='March' year='2015' />
</front>
<seriesInfo name='I-D' value='draft-ietf-sfc-nsh-00 (work in progress)' />
</reference>
<reference anchor='ietf-sfc-arch'>
<front>
<title>Service Function Chaining (SFC) Architecture</title>
<author surname='Halpern' initials='J.'/>
<author surname='Pignataro' initials='C.'/>
<date month='May' year='2015' />
</front>
<seriesInfo name='I-D' value='draft-ietf-sfc-architecture-08 (work in progress)' />
</reference>
<reference anchor='guichard-sfc-nsh-dc-allocation'>
<front>
<title>Network Service Header (NSH) Context Header Allocation (Data Center)</title>
<author surname='Guichard' initials='J.'/>
<author surname='Smith' initials='M.'/>
<author surname='Kumar' initials='S.'/>
<author surname='Majee' initials='S.'/>
<author surname='Agarwal' initials='P.'/>
<author surname='Glavin' initials='K.'/>
<author surname='Laribi' initials='Y.'/>
<date month='December' year='2014' />
</front>
<seriesInfo name='I-D' value='draft-guichard-sfc-nsh-dc-allocation-01 (work in progress)' />
</reference>
<reference anchor='itu-e-164'>
<front>
<title>The international public telecommunication numbering plan</title>
<author fullname='Telecommunication Standardization Sector Of ITU'/>
<date month='November' year='2010' />
</front>
<seriesInfo name='ITU-T' value='E.164' />
</reference>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 01:33:59 |