StatusofthisMemo

ThisInternetDraftissubmittedinfullconformancewith
the
provisionsofBCP78andBCP79.

InternetDraftsareworkingdocumentsoftheInternet
Engineering
TaskForce(IETF).Notethatothergroupsmay

1. Requirements Language

Thekeywords"MUST","MUSTNOT","REQUIRED","SHALL",
"SHALLNOT",
"SHOULD","SHOULDNOT","RECOMMENDED","MAY",and"OPTIONAL"
inthis
documentaretobeinterpretedasdescribedinRFC2119
[RFC2119].

StatusofthisMemo

ThisInternetDraftissubmittedinfullconformancewith
the
provisionsofBCP78andBCP79.

InternetDraftsareworkingdocumentsoftheInternet
Engineering
TaskForce(IETF).Notethatothergroupsmayalso
distribute
workingdocumentsasInternetDrafts.Thelistofcurrent
Internet
Draftsisathttp://datatracker.ietf.org/drafts/current/.

InternetDraftsaredraftdocumentsvalidforamaximumof
sixmonths
andmaybeupdated,replaced,orobsoletedbyother
documentsatany
time.ItisinappropriatetouseInternetDraftsas
reference
materialortocitethemotherthanas"workinprogress."

ThisInternetDraftwillexpireonJanuary1,2018.
CopyrightNotice

Copyright(c)2017IETFTrustandthepersonsidentifiedas
the
documentauthors.Allrightsreserved.

ThisdocumentissubjecttoBCP78andtheIETFTrust's
Legal
ProvisionsRelatingtoIETFDocuments
(http://trustee.ietf.org/licenseinfo)ineffectonthedate
of
publicationofthisdocument.Pleasereviewthesedocuments
carefully,astheydescribeyourrightsandrestrictions
withrespect
tothisdocument.CodeComponentsextractedfromthis
documentmust
includeSimplifiedBSDLicensetextasdescribedinSection
4.eof
theTrustLegalProvisionsandareprovidedwithoutwarranty
as
describedintheSimplifiedBSDLicense.

Quinn&ElzurExpiresJanuary1,2018
[Page2]

InternetDraftNetworkServiceHeader
June2017
TableofContents

1.RequirementsLanguage.................
...2
2.Introduction......................
...4
2.1.DefinitionofTerms................
...4
2.2.ProblemSpace...................
...5
2.3.NSHbasedServiceChaining.............
...5
3.NetworkServiceHeader.................
...7
3.1.NetworkServiceHeaderFormat...........
...7
3.2.NSHBaseHeader..................
...7
3.3.ServicePathHeader................
...10
3.4.NSHMDType1...................
...10
3.5.NSHMDType2...................
...11
3.5.1.OptionalVariableLengthMetadata.......
...12
4.NSHActions......................
...14
5.NSHEncapsulation...................
...16
6.FragmentationConsiderations..............
...17
7.ServicePathForwardingwithNSH............
...18
7.1.SFFsandOverlaySelection.............
...18
7.2.MappingNSHtoNetworkTransport..........
...20
7.3.ServicePlaneVisibility..............
...21
7.4.ServiceGraphs...................
...21
8.PolicyEnforcementwithNSH..............
...22
8.1.NSHMetadataandPolicyEnforcement........
...22
8.2.Updating/AugmentingMetadata............
...24
8.3.ServicePathIdentifierandMetadata........
...25
9.SecurityConsiderations................
...27
10.Contributors......................
...28
11.Acknowledgments....................
...31
12.IANAConsiderations..................
...32
12.1.NSHEtherType...................
...32
12.2.NetworkServiceHeader(NSH)Parameters......
...32
12.2.1.NSHBaseHeaderReservedBits.........
...32
12.2.2.NSHVersion..................
...32
12.2.3.MDTypeRegistry................
...32
12.2.4.MDClassRegistry...............
...33
12.2.5.NSHBaseHeaderNextProtocol.........
...33
12.2.6.NewIETFassignedMDTypeRegistry.......
...34
13.References.......................
...35
13.1.NormativeReferences................
...35
13.2.InformativeReferences...............
...35
Authors'Addresses.....................
...37
Quinn&ElzurExpiresJanuary1,2018
[Page3]

InternetDraftNetworkServiceHeader
June2017

2. Introduction

Servicefunctionsarewidelydeployedandessentialinmany
networks.
Theseservicefunctionsprovidearangeoffeaturessuchas
security,
WANacceleration,andserverloadbalancing.Service
functionsmay
beinstantiatedatdifferentpointsinthenetwork
infrastructure
suchasthewideareanetwork,datacenter,campus,andso
forth.

PriortodevelopmentoftheSFCarchitecture[RFC7665]and
the
protocolspecifiedinthisdocument,currentservice
function
deploymentmodelshavebeenrelativelystatic,andboundto
topology
forinsertionandpolicyselection.Furthermore,theydo
notadapt
welltoelasticserviceenvironmentsenabledby
virtualization.

Newdatacenternetworkandcloudarchitecturesrequiremore
flexible
servicefunctiondeploymentmodels.Additionally,the
transitionto
virtualplatformsrequiresanagileserviceinsertionmodel
that
supportsdynamicandelasticservicedelivery;themovement
of
servicefunctionsandapplicationworkloadsinthenetwork
andthe
abilitytoeasilybindservicepolicytogranular
informationsuchas
persubscriberstateandsteertraffictotherequisite
service
function(s)arenecessary.

NSHdefinesanewserviceplaneprotocolspecificallyfor
the
creationofdynamicservicechainsandiscomposedofthe
following
elements:

1.ServiceFunctionPathidentification

2.IndicationoflocationwithinaServiceFunctionPath.

3.Optional,perpacketmetadata(fixedlengthor
variable).

NSHisdesignedtobeeasytoimplementacrossarangeof
devices,
bothphysicalandvirtual,includinghardwareplatforms.

AnNSHawarecontrolplaneisoutsidethescopeofthis
document.

[RFC7665]providesanoverviewofaservicechaining
architecture
thatclearlydefinestherolesofthevariouselementsand
thescope
ofaservicefunctionchainingencapsulation.NSHisthe
SFC
encapsulationreferencedinRFC7665.

2.1. Definition of Terms

Quinn&ElzurExpiresJanuary1,2018
[Page4]

InternetDraftNetworkServiceHeader
June2017

Classification:Definedin[RFC7665].

Classifier:Definedin[RFC7665].

Metadata:Definedin[RFC7665].

NetworkLocator:dataplaneaddress,typicallyIPv4orIPv6,
usedto
sendandreceivenetworktraffic.

NetworkNode/Element:Devicethatforwardspacketsor
framesbased
onouterheader(i.e.transport)information.

NetworkOverlay:Logicalnetworkbuiltontopofexisting
network
(theunderlay).Packetsareencapsulatedortunneledto
create
theoverlaynetworktopology.

ServiceClassifier:Logicalentityprovidingclassification
function.Sincetheyarelogical,classifiersmaybeco
resident
withSFCelementssuchasSFsorSFFs.Service
classifiers
performclassificationandimposeNSH.Theinitial
classifier
imposestheinitialNSHandsendstheNSHpackettothe
firstSFF
inthepath.Noninitial(i.e.subsequent)
classificationcan
occurasneededandcanalter,orcreateanewservice
path.

ServiceFunction(SF):Definedin[RFC7665].

ServiceFunctionChain(SFC):Definedin[RFC7665].

ServiceFunctionForwarder(SFF):Definedin[RFC7665].

ServiceFunctionPath(SFP):Definedin[RFC7665].

SFCProxy:Definedin[RFC7665].

2.2. Problem Space

NetworkServiceHeader(NSH)addressesseverallimitations
associated
withservicefunctiondeployments.[RFC7498]providesa
comprehensivereviewofthoseissues.

2.3. NSH-based Service Chaining

NSHcreatesadedicatedserviceplane,morespecifically,
NSH
enables:

1.TopologicalIndependence:Serviceforwardingoccurs
withinthe
serviceplane,theunderlyingnetworktopologydoesnot
require
modification.NSHprovidesanidentifierusedtoselect
the

Quinn&ElzurExpiresJanuary1,2018
[Page5]

InternetDraftNetworkServiceHeader
June2017
networkoverlayfornetworkforwarding.

2.ServiceChaining:NSHenablesservicechainingper
[RFC7665].
NSHcontainspathidentificationinformationneededto
realizea
servicepath.Furthermore,NSHprovidestheabilityto
monitor
andtroubleshootaservicechain,endtoendvia
servicespecific
OAMmessages.NSHfieldscanbeusedbyadministrators
(via,for
example,atrafficanalyzer)toverify(account,ensure
correct
chaining,providereports,etc.)thepathspecificsof
packets
beingforwardedalongaservicepath.

3.NSHprovidesamechanismtocarrysharedmetadata
between
participatingentitiesandservicefunctions.The
semanticsof
thesharedmetadataiscommunicatedviaacontrolplane,
whichis
outsidethescopeofthisdocument,toparticipating
nodes.
[SFCCP]providesanexampleofsuchinsection3.3.
Examplesof
metadataincludeclassificationinformationusedfor
policy
enforcementandnetworkcontextforforwardingpost
service
delivery.Sharingthemetadataallowsservicefunctions
toshare
initialandintermediateclassificationresultswith
downstream
servicefunctionssavingreclassification,whereenough
informationwasenclosed.

4.NSHoffersacommonandstandardsbasedheaderfor
service
chainingtoallnetworkandservicenodes.
5.TransportAgnostic:NSHistransportindependent.An
appropriate
(foragivendeployment)networktransportprotocolcan
beused
totransportNSHencapsulatedtraffic.Thistransport
mayform
anoverlaynetworkandifanexistingoverlaytopology
provides
therequiredservicepathconnectivity,thatexisting
overlaymay
beused.

Quinn&ElzurExpiresJanuary1,2018
[Page6]

InternetDraftNetworkServiceHeader
June2017

3. Network Service Header

ANetworkServiceHeader(NSH)containsservicepath
informationand
optionallymetadatathatareaddedtoapacketorframeand
usedto
createaserviceplane.Anoutertransportheaderis
imposed,onNSH
andtheoriginalpacket/frame,fornetworkforwarding.

AServiceClassifieraddsNSH.NSHisremovedbythelast
SFFinthe
servicechainorbyaSFthatconsumesthepacket.

3.1. Network Service Header Format

NSHiscomposedofa4byte(allreferencestobytesinthis
document
referto8bitbytes,oroctets)BaseHeader,a4byte
ServicePath
HeaderandoptionalContextHeaders,asshowninFigure1
below.

012345678901234567890123456789
01
++++++++++++++++++++++++++++++
+++
|BaseHeader
|
++++++++++++++++++++++++++++++
+++
|ServicePathHeader
|
++++++++++++++++++++++++++++++
+++
|
|
~ContextHeader(s)
~
|
|
++++++++++++++++++++++++++++++
+++

Figure1:NetworkServiceHeader

Baseheader:providesinformationabouttheserviceheader
andthe
payloadprotocol.

ServicePathHeader:providepathidentificationand
locationwithin
aservicepath.

Contextheader:carrymetadata(i.e.contextdata)alonga
service
path.

3.2. NSH Base Header

0123456789012345678901234567
8901
++++++++++++++++++++++++++++
+++++
|Ver|O|R|TTL|Length|R|R|R|R|MDType|Next
Protocol|
++++++++++++++++++++++++++++
+++++

Quinn&ElzurExpiresJanuary1,2018
[Page7]

InternetDraftNetworkServiceHeader
June2017

Figure2:NSHBaseHeader

BaseHeaderFieldDescriptions:

Version:Theversionfieldisusedtoensurebackward
compatibility
goingforwardwithfutureNSHupdates.ItMUSTbesetto
0x0bythe
sender,inthisfirstrevisionofNSH.Giventhewidespread
implementationofexistinghardwarethatusesthefirst
nibbleafter
anMPLSlabelstackforECMPdecisionprocessing,this
document
reservesversion01andthisvalueMUSTNOTbeusedin
future
versionsoftheprotocol.Pleasesee[RFC7325]forfurther
discussionofMPLSrelatedforwardingrequirements.

Obit:SettingthisbitindicatesanOperations,
Administration,and
Maintenance(OAM)packet.Theactualpacketformatand
processingof
SFCOAMmessagesisoutsidethescopeofthisspecification
(see
[oamframe]).

SF/SFF/SFCProxy/Classiferimplementationsthatdonot
supportSFC
OAMproceduresSHOULDdiscardpacketswithObitset,but
MAYsupport
aconfigurableparametertoenableforwardingreceivedSFC
OAM
packetsunmodifiedtothenextelementinthechain.
ForwardingOAM
packetsunmodifiedbySFCelementsthatdonotsupportSFC
OAM
proceduresmaybeacceptableforasubsetofOAMfunctions,
butcan
resultinunexpectedoutcomesforothers,thusitis
recommendedto
analyzetheimpactofforwardinganOAMpacketforallOAM
functions
priortoenablingthisbehavior.Theconfigurableparameter
MUSTbe
disabledbydefault.

TheObitMUSTbesetforOAMpacketsandMUSTNOTbeset
fornonOAM
packets.TheObitMUSTNOTbemodifiedalongtheSFP.
TTL:IndicatesthemaximumSFFhopsforanSFP.Theinitial
TTL
valueSHOULDbeconfigurableviathecontrolplane;the
configured
initialvaluecanbespecifictooneormoreSFPs.Ifno
initial
valueisexplicitlyprovided,thedefaultinitialTTLvalue
63MUST
beused.EachSFFinvolvedinforwardinganNSHpacketMUST
decrementtheTTLvalueby1priortoNSHforwardinglookup.
Decrementingby1fromanincomingvalueof0shallresult
inaTTL
valueof63.ThepacketMUSTNOTbeforwardedifTTLis,
after
decrement,0.

Allotherflagfieldsarereservedforfutureuse.Reserved
bits
MUSTbesettozerouponoriginationandMUSTbepreserved
unmodified
byotherNSHsupportingelements.Elementswhichdonot
understand
themeaningofanyofthesebitsMUSTnotmodifytheir
actionsbased
onthoseunknownbits.

Quinn&ElzurExpiresJanuary1,2018
[Page8]

InternetDraftNetworkServiceHeader
June2017
anticsofthevariablelengthContextHeader(s)
arenotdefinedinthisdocument

TheformatoftheBaseHeaderandtheServicePathHeaderis
invariant,andnotaffectedbyMDType.

NSHimplementationsMUSTsupportMDtype=0x1andMDType
0x2(where
thelengthisofvalue0x2).NSHimplementationsSHOULD
supportMD
Type0x2withlength>0x2.Thereexists,however,amiddle
ground,
whereinadevicewillsupportMDType0x1(aspertheMUST)
metadata,
yetbedeployedinanetworkwithMDType0x2metadata
packets.In
thatcase,theMDType0x1node,MUSTutilizethebase
headerlength
fieldtodeterminetheoriginalpayloadoffsetifit
requiresaccess
totheoriginalpacket/frame.

NextProtocol:indicatestheprotocoltypeofthe
encapsulateddata.
NSHdoesnotaltertheinnerpayload,andthesemanticson
theinner
protocolremainunchangedduetoNSHservicefunction
chaining.
PleaseseeIANAConsiderationssectionbelow.

ThisdocumentdefinesthefollowingNextProtocolvalues:

0x1:IPv4
0x2:IPv6
0x3:Ethernet
0x4:NSH
0x5:MPLS