One document matched: draft-napper-sfc-nsh-mobility-allocation-02.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'>
<!ENTITY rfc7665 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.7665.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-02'>
<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>
<author initials='P.' surname='Muley'
fullname='Praveen Muley'>
<organization>Alcatel-Lucent</organization>
<address>
<email>praveen.muley@alcatel-lucent.com</email>
</address>
</author>
<author initials='W.' surname='Hendericks'
fullname='Wim Hendericks'>
<organization>Alcatel-Lucent</organization>
<address>
<email>Wim.Henderickx@alcatel-lucent.com</email>
</address>
</author>
<date day='4' month='November' 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) provides 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 fixed and mobile broadband service provider networks. Supporting use cases describing the need for a metadata header in these contexts 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='RFC7665' />.</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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| R | Sub | Tag | Context ID | CH1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sub/Endpoint ID ~ CH2
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Sub/Endpoint ID (cont.) | CH3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ServiceTag | CH4
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
</figure>
<t><xref target='fig_mobility_context' /> provides a high-level description of the fields in the recommended allocation of the fixed context headers for a mobility context.</t>
</section>
<section anchor='sec_mobility_spec' title='Broadband Allocation Specifics'>
<t>The intended use for each of the context header allocations is as follows:
<list style='hanging'>
<t hangText="R"> - Reserved.</t>
<t hangText="Sub"> - Sub/Endpoint ID type field. These bits determine the type of the
64-bit Sub/Endpoint ID field that spans CH2 and CH3.</t>
<t hangText="Tag"> - The Tag field indicates the type of the ServiceTag field in CH4.</t>
<t hangText="Context ID"> - The Context ID field allows the Subscriber/Endpoint ID field to be scoped. For example, the Context ID field could contain the incoming VRF, VxLAN VNID, VLAN, or policy identifier within which the Subscriber/Endpoint ID field is defined.</t>
<t hangText="Sub/App ID"> - 64-bit length Subscriber/Endpoint identifier (e.g., IMSI, MSISDN, or implementation-specific Endpoint ID) of the corresponding subscriber/machine/application for the flow. This field is typed by the value of the Sub field as follows:
<list style='hanging'>
<t hangText="000"> - If the Sub field is not set, then the 64-bit Sub/Endpoint ID
field is an opaque field that can be used or ignored by service functions as determined by the control plane.</t>
<t hangText="001"> - The Sub/Endpoint ID field contains an IMSI <xref target='itu-e-164' />.</t>
<t hangText="010"> - The Sub/Endpoint ID field contains an MSISDN (8-15 digit) <xref target='itu-e-164' />.</t>
<t hangText="011"> - The Sub/Endpoint ID field contains a 64-bit identifier that can be used to group flows (e.g., in Machine-to-Machine, M2M).</t>
<t hangText="100-111"> - Reserved.</t>
</list>
</t>
<t hangText="ServiceTag"> - A ServiceTag is a unique identifier that can carry metadata specific to the flow or subscriber identified in the Sub/App ID field. Some types for this field are specified by the Tag field as follows:
<list style='hanging'>
<t hangText="000"> - If the Tag field is not set, then the ServiceTag field in CH4 is an opaque field that can be used or ignored by service functions as determined by the control plane.</t>
<t hangText="001"> - The ServiceTag field in CH4 contains information related to the Radio Access Network (RAN) for the subscriber as follows in <xref target='fig_ran_tag' />. Note that these values should correspond to those that can be obtained for the flow from the corresponding 3GPP PCRF (Policy and Charging Rules Function) component using Diameter as described in <xref target='TS.29.230' />.
<figure anchor='fig_ran_tag' title='Service Tag RAN 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CAN | QoS |U| Con | App Id | Rsvd | CH4
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
</figure>
<list style='hanging'>
<!-- ToS-Traffic-Class AVP (Diameter AVP code 1014): 16 bits -->
<t hangText="CAN"> - IP-CAN-Type (Diameter AVP code 1027).</t>
<t hangText="QoS"> - QoS-Class-Identifier AVP (Diameter AVP code 1028).</t>
<t hangText="U"> - QoS-Upgrade AVP (Diameter AVP code 1030).</t>
<t hangText="Con"> - Congestion level.</t>
<t hangText="App Id"> - Application ID describing the flow type. Allocation of IDs is done in the control plane and is out of the scope of this document.</t>
<t hangText="Rsvd"> - Reserved.</t>
</list>
</t>
<t hangText="010-111"> - Reserved.</t>
</list>
</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;
&rfc7665;
<!--
<reference anchor='TS.23.203'>
<front>
<title>Policy and charging control architecture</title>
<author fullname='3GPP' />
<date month='December' year='2013' />
</front>
<seriesInfo name='3GPP TS' value='23.203 12.3.0' />
<format type='HTML' target='http://www.3gpp.org/DynaReport/23203.htm' />
</reference>
-->
<reference anchor='TS.29.230'>
<front>
<title>Diameter applications; 3GPP specific codes and identifiers</title>
<author fullname='3GPP' />
<date month='September' year='2015' />
</front>
<seriesInfo name='3GPP TS' value='29.230 13.2.0' />
<format type='HTML' target='http://www.3gpp.org/DynaReport/29230.htm' />
</reference>
<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-05 (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='July' year='2015' />
</front>
<seriesInfo name='I-D' value='draft-ietf-sfc-nsh-01 (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='June' year='2015' />
</front>
<seriesInfo name='I-D' value='draft-guichard-sfc-nsh-dc-allocation-02 (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:56 |