Advertising Service Functions Using IS-ISHuaweixuxiaohu@huawei.comHuaweieric.wu@huawei.comCienahshah@ciena.comTelefonica I+DRonda de la Comunicacion, s/nSur-3 building, 3rd floorMadrid,28050Spainluismiguel.contrerasmurillo@telefonica.comhttp://people.tid.es/LuisM.Contreras/
Routing Area
ISIS Working GroupSampleDraftThe MPLS source routing mechanism developed by Source Packet Routing
in Networking (SPRING) WG can be leveraged to realize a unified source
routing instruction which works across both IPv4 and IPv6 underlays in
addition to the MPLS underlay. The unified source routing instruction
can be used to realize a transport-independent service function chaining
by encoding the service function path information or service function
chain information as an MPLS label stack. This document describes how to
advertise service functions and their corresponding attributes (e.g.,
service function label) using IS-IS.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 RFC 2119. describes how to
leverage the unified source routing instruction to realize a
transport-independent service function chaining by encoding the Service
Function Path (SFP) or Service Function Chain (SFC) information as an
MPLS label stack. To allow a service classifier to attach the MPLS label
stack which represents a particular SFP or SFC to the selected traffic,
the service classifier needs to know on which Service Function Forwarder
(SFF) a given Service Function (SF) is located and what service function
label is used to indicate that SF. This document describes how to
advertise SFs and their corresponding attributes (e.g., service function
label) using IS-IS.This memo makes use of the terms defined in and .SFFs within the SFC domain need to advertise each SF they are
offering by using a new sub-TLV of the IS-IS Router CAPABILITY TLV . This new sub-TLV is called as Service Function
sub-TLV. The Service Function sub-TLV could appear multiple times wihin
a given IS-IS Router CAPABILITY TLV when more than one SF needs to be
advertised. The scope of the advertisement depends on the application
but it is recommended that it SHOULD be domain-wide. To support the
approach of encoding SFP information in the form of an MPLS label stack
as described in , SFFs
SHOULD allocate a locally significant MPLS label to each SF they are
offering. Therefore, SFFs need to advertise the corresponding service
function label to each SF they are offering by using a sub-TLV of the
above Service Function sub-TLV, called SF Label sub-TLV. Type: TBD1.Length: variable.Service Function Identifier: A unique identifier that
represents an SF within an SFC-enabled domain.Sub-TLVs: contains zero or more sub-TLVs corresponding to the
particular attributes of a given SF. The SF Label sub-TLV as
defined in Section 3.2 is one such sub-TLV. Other sub-TLVs are to
be defined in the future.Type: TBD2.Length: 3.Value: The rightmost 20 bits represent an MPLS label which is
the SF Label of the corresponding SF.TBD.This document includes a request to IANA for allocating type codes
for the Service Function sub-TLV and the SF Label sub-TLV.This document does not introduce any new security risk.