Internet DRAFT - draft-ypal-sfc-dhcp-option-for-nsh-for-sfp
draft-ypal-sfc-dhcp-option-for-nsh-for-sfp
Service Function Chaining (sfc) Yogendra Pal
Internet-Draft Cisco
Intended status: Experimental Venkata SRG
Expires: February 16, 2017 Citrix
Vikram Menon
Ericsson
August 16, 2016
DHCP option for NSH in Service Function Path (SFP)
draft-ypal-sfc-dhcp-option-for-nsh-for-sfp-02
Abstract
This draft specifies Dynamic Host Configuration Protocol option
(both DHCPv4 and DHCPv6) for NSH aware clients participating in
the service function path(SFP) of the service chaining. As part
of this proposal SFF and SF will receive the SFP information
containing Service Path Identifier(SPI), Transport protocol and
Nexthop(NH) address of subsequent SFF/SF.
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 February 16, 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
Pal, et al. Expires Feb 16, 2017 [Page 1]
Internet-Draft DHCP option for NSH in SFP August 2016
to this document. Code Components extracted from this document must
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. Requirements Language .......................................... 2
2. Introduction ................................................... 2
2.1 Terminology ................................................ 3
3. Model and Applicability ........................................ 3
3.1 Example service chain network .............................. 4
4. SFP DHCP Option Formats ........................................ 4
4.1 DHCPv4 Options ............................................. 7
4.2 DHCPv6 Options ............................................. 8
5. Request and Processing DHCP SFP Option ......................... 8
5.1 DHCPv4 Client Behaviour .................................... 8
5.2 DHCPv6 Client Behaviour .................................... 9
5.3 DHCP Server Behaviour ...................................... 9
6. Security Considerations ........................................ 10
7. IANA Considerations ............................................ 10
8. Acknowledgements ............................................... 11
9. References ..................................................... 11
9.1. Normative References ...................................... 11
9.2. Informative References .................................... 11
1. Requirements Language
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 [RFC2119].
2. Introduction
In NSH aware service chaining model, SFF needs to be provisioned with
SFP information. In the current environment, the operator
manually provisions each network elements(SFF) with SFP information.
This does not scale well when on-demand service functions are introduced
and brought down in virtualized networks in cloud, datacenter, and so
Pal, et al. Expires Feb 16, 2017 [Page 2]
Internet-Draft DHCP option for NSH in SFP August 2016
forth deployments. This draft is trying to automate this network rollout
of service chaining using the DHCP option. Each SFF willing to
participate in NSH aware service chain model will indicate its interest
to the DHCP server for SFP and gets provisioned accordingly from the
DHCP server.
2.1 Terminology
This document uses the terminology defined in draft-ietf-sfc-nsh with
respect to service function chain.
DHCP client: A DHCP [1] client is an Internet host that uses DHCP to
obtain configuration parameters such as a network address.
DHCP server: A DHCP server is an Internet host that returns
configuration parameters to DHCP clients.
Service Function Forwarder (SFF): A service function forwarder is
responsible for delivering traffic received from the SFCNF to one
or more connected service functions, and from service functions to
the SFC network forwarder(SFCNF).
Service Function (SF): A function that is responsible for specific
treatment of received packets. A service function can act at the
network layer or other OSI layers. A service function can be a
virtual instance or be embedded in a physical network element.
One of multiple service functions can be embedded in the same
network element. Multiple instances of the service function can
be enabled in the same administrative domain.
Service Function Path (SFP): The instantiation of a SFC in the
network. Packets follow a service function path from a classifier
through the requisite service functions.
3. Model and Applicability
In service chaining model, SFC controller will provision SFF with
details of service function paths SFP(s). In order to provision SFP
details to SFF(s), controller needs some mechanism to configure the
SFF. DHCP protocol is one of the existing mechanism for provisioning
various network information to any DHCP clients.
Existing DHCP version 4 and 6 will be extended to incorporate option
of provisioning dynamically SFP details to SFF. In this case,
controller can be considered to act as DHCP server.
Pal, et al. Expires Feb 16, 2017 [Page 3]
Internet-Draft DHCP option for NSH in SFP August 2016
3.1 Example service chain network
See Figure 1, depicting SFF (DHCP clients) interacting with SFC
controller (DHCP server) to register and getting provisioned
with SFP details.
+-------------------------------------------------+
| SFC Control Plane |
| (DHCP Server) |
+-------------------------------------------------+
^ ^
| |
+-------------------------------------------------+
| DHCP protocol exchanges |
| provisioning Service function Path (SFP) |
| (SFP1 + SFP2) to SFF Clients |
+-------------------------------------------------+
| |
| |
v v
+--------+ +---------+
| SFF | ---(SFP1)---> | SFF |
|(DHCPv4 | <---(SFP2)--- | (DHCPv6 |
| client)| ........................... | client)|
+--------+ +---------+
Figure 1: SFF enabled DHCP clients in service chaining
4. SFP DHCP Option Formats
The SFP information is composed of a generic SFP header, followed
by one or more SFP entries, as shown in Figure 2.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version | Count | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ <SFP Entries> ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: SFP Information
Pal, et al. Expires Feb 16, 2017 [Page 4]
Internet-Draft DHCP option for NSH in SFP August 2016
Version: SFP Information version (0), 1 Octet.
Count: This field indicates total number of SFP entries.
This is 1 octet.
Reserved: MUST be set zero.
SFP Entries: One or more SFP entries, each composed Transport type,
Protocol ID, SP header (SPH) and followed by one or
more SFP-NH entries, as shown in Figure 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Transport Type | Count | Protocol ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Service Path (SP) Header |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ <SFP-NH Entries> ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: SFP Entry
Transport Type: This field indicates the type of transport layer
attribute. Examples: L2, L3, L4. Values for transport type are
following:
-------------------------------------
| Transport Types| Value(in decimal)|
-------------------------------------
| L2 | 2 |
| L3 | 3 |
| L4 | 4 |
-------------------------------------
Table 1: Transport Types
Count: This field indicates total number of SFP-NH entries
with the given Transport Type, Protocol ID and SP Header.
This is 1 octet.
Protocol ID: This field indicates the actual protocol layer
encapsulating the NSH. This is to be read and understood in
accordance with Transport Type field. Values for this field
are following:
-------------------------------------
| Protocol ID | Value(in decimal)|
-------------------------------------
| Ethernet | 35151 |
| VXLAN-gpe | 4790 |
| GRE | 47 |
| UDP | 6633 |
-------------------------------------
Table 2: Protocol ID
Pal, et al. Expires Feb 16, 2017 [Page 5]
Internet-Draft DHCP option for NSH in SFP August 2016
Example of {Transport Type, Protocol ID} SHOULD be seen as
below:
-------------------------------------
| Transport Type | Protocol ID |
-------------------------------------
| 2 | 35151 |
| 2 | 4790 |
| 3 | 47 |
| 4 | 6633 |
-------------------------------------
Table 3: Association of Transport
Type and Protocol ID
SP header is composed of Service Path ID and Service Index,
shown in Figure 4.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Service Path ID | Service Index |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: Service Function (SF) Header
Service Path ID (SPI): 24 bits
Service Index (SI): 8 bits
As defined in draft
[https://tools.ietf.org/html/draft-ietf-sfc-nsh-05#section-3.3]
SFP-NH Entries: One or more SFP-NH entries, as shown in Figure 5.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SFP-NH Type | Count | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ <SFP-NH Addresses> ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: SFP-NH Entry
Pal, et al. Expires Feb 16, 2017 [Page 6]
Internet-Draft DHCP option for NSH in SFP August 2016
SFP-NH Type: Nexthop address types (1 Octet).
-------------------------------------
| SFP-NH Type | Value (in decimal)|
-------------------------------------
| IPv4 | 1 |
| IPv6 | 2 |
| Ethernet | 3 |
-------------------------------------
Table 4: SFP-NH Type Values
Count: This field indicates total number of SFP-NH addresses
with the given SFP-NH type. This is 1 octet
Reserved: MUST be set zero.
SFP-NH addresses: One or more SFP nexthop addresses of same
SFP-NH type.
4.1 DHCPv4 Options
4.1.1 DHCPv4 NSH SFP Option
The NSH SFP option can be used by DHCP servers to communicate SFP
information to DHCPv4 clients, either in a stateful DHCPv4 address
configuration or renewal transaction, or in a stateless information
request (DHCPINFORM).
The format of NSH SFP option for DHCPv4 is:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Code | Len | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. SFP Information .
. (variable length) .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: DHCPv4 NSH SFP option
Code: OPTION_NSH_SFP
(TBD1, 8 bit value, to be assigned by IANA).
Len: Length of SFP Information in 32 bit words.
Reserved: MUST be set zero.
SFP Info: Service function path details.
Refer Section 4 to see format and details of SFP information.
Pal, et al. Expires Feb 16, 2017 [Page 7]
Internet-Draft DHCP option for NSH in SFP August 2016
4.2 DHCPv6 Options
4.2.1 DHCPv6 NSH SFP Option
The NSH SFP option can be used by DHCPv6 servers to communicate SFP
information to DHCPv6 clients, either in a stateful DHCPv6 address
configuration or renewal transaction, or in a stateless information
request (Information-request).
The format of NSH SFP option for DHCPv6 is:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION_NSH_SFP | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. SFP Info .
. (variable length) .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: DHCPv6 NSH SFP option
option-code: OPTION_NSH_SFP
(TBD2, 16 bit value, to be assigned by IANA).
option-len: Length of SFP Information in octets.
SFP Info: Service function path details.
Refer section 4 to see format and details of SFP information.
5. Request and Processing DHCP SFP Option
In the service chaining model, SFF DHCP clients willing to participate
in SFP can request SFP information from the DHCP server using the
OPTION_NSH_SFP option. Details of this request in DHCPv4 and DHCPv6
are detailed in below sections.
5.1 DHCPv4 Client Behaviour
DHCPv4 client enabled with the capability of doing SFF/SF role in SFP
MUST request for SFP information in DHCPDISCOVER and DHCPREQUEST of
DHCPv4 protocol exchanges. Client behaviour is detailed below.
5.1.1 Requesting OPTION_NSH_SFP
SFF enabled DHCPv4 clients interested in SFP MUST send the
OPTION_NSH_SFP option to the DHCPv4 server along with other
options in Parameter Request List (PRL). DHCPv4 clients supporting this
option, should support FORCERENEW message exchange for any dynamic
updates in SFP from DHCPv4 server.
DHCP clients that support the SFF option must handle the case where
SFF functionality is configured after the client has been started.
This can be handled by the client either by renewing its lease when
SFF functionality is configured, or by sending a DHCPINFORM message.
Pal, et al. Expires Feb 16, 2017 [Page 8]
Internet-Draft DHCP option for NSH in SFP August 2016
5.2 DHCPv6 Client Behaviour
DHCPv6 client enabled with capability of doing SFF/SF role in SFP can
request for SFP information at different stages of DHCPv6 protocol
exchanges. Client behaviour is detailed below.
5.2.1 Requesting OPTION_NSH_SFP
SFF enabled DHCPv6 client interested in SFP MUST send the
OPTION_NSH_SFP option to the DHCPv6 server along with other
options in Option Request Option (ORO).
DHCPv6 clients that support the SFF option must handle the case where
SFF functionality is configured after the client has been started.
This can be handled by the client either by renewing its lease when
SFF functionality is configured, or by sending a Information-request
message.
DHCPv6 clients supporting this option, should support reconfigure
message exchange for any dynamic updates in SFP from DHCPv6 server.
5.3 DHCP Server Behaviour
DHCPv4 and DHCPv6 server if configured to provide service chaining
SFP parameters, SHOULD provision the SFF clients as per their
administrative policy. DHCPv4 and DHCPv6 server can receive request
for option OPTION_NSH_SFP from clients in Parameter Request List (PRL)
and Option Request Option (ORO) respectively.
When a DHCPv4 and DHCPv6 server has been configured with different
SFP parameters, the administrator or agent that updated the
configuration should trigger FORCERENEW/DHCPINFORM and Reconfigure
messages respectively for any DHCPv4 and DHCPv6 clients that now
have stale configurations.
5.3.1 Processing OPTION_NSH_SFP Request
Clients do not send OPTION_NSH_SFP to servers; therefore, servers
that receive this option should take no special action as a result
of having received it.
Pal, et al. Expires Feb 16, 2017 [Page 9]
Internet-Draft DHCP option for NSH in SFP August 2016
5.3.2 Notifying update in SFP path to SFF
Any update to notify about change in service chain path is notified
to SFF client using Reconfigure Message as defined in section 22.19 of
[RFC3315] for DHCPv6 and FORCERENEW message exchange as defined in
[RFC3203] of DHCPv4.
6. Security Considerations
Since there is no privacy protection for DHCP messages, an
eavesdropper who can monitor the link between the DHCP server and
requesting client can discover the SFP information.
To minimize the unintended exposure of SFP, the OPTION_NSH_SFP
option SHOULD be returned by DHCP servers only when the DHCP client
has requested this option in its request (Section 9.8 of [RFC2132]).
Networks where this option is used SHOULD use link-layer security and
integrity protection. Additionally, such networks should filter out
rogue DHCP messages (RFC 7610).
7. IANA Considerations
This document defines a new DHCP option, entitled "OPTION_NSH_SFP"
(see Section 4.1 and 4.2) for DHCPv4 and DHCPv6 respectively. Assigned a
value of TBD1 and TBD2 from the DHCPv4 [to be removed upon publication:
http://www.iana.org/assignments/bootp-dhcp-parameters]
[DHCP-OPTIONS] [DHCP-IANA] and DHCPv6 (Section 24.3 of RFC 3315)
option space defined respectively.
Tag Name Data Length Meaning
---- ---- ------------ -------
TBD1 OPTION_NSH_SFP 1 octet DHCPv4 NSH SFP option
TBD2 OPTION_NSH_SFP 2 octet DHCPv6 NSH SFP option
IANA is requested to create a new "DHCP NSH SFP parameters" registry.
The following sub-sections request new registries within the
"DHCP NSH SFP parameters" registry.
7.1 Transport types
--------------------------------------------------
| Transport Type | Description | Reference |
--------------------------------------------------
| 2 | L2 transports | This document |
| | | |
| 3 | L3 transports | This document |
| | | |
| 4 | L4 transports | This document |
--------------------------------------------------
Table 5
Pal, et al. Expires Feb 16, 2017 [Page 10]
Internet-Draft DHCP option for NSH in SFP August 2016
7.2 SFP Nexthop types
------------------------------------------------
| SFP-NH Type | Description | Reference |
------------------------------------------------
| 1 | IPv4 | This document |
| | | |
| 2 | IPv6 | This document |
| | | |
| 3 | Ethernet | This document |
------------------------------------------------
Table 6
7.3 Protocol ID
Protocol ID values referenced in this draft Section 4, Table 2 is
more towards using the values and no action is required from IANA
towards it.
8. Acknowledgements
The authors would like to thank Ted Lemon, Youcef Laribi for the
constructive comments to initial draft.
9. References
9.1 Normative References
[RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
August 1980.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol",
RFC 2131, March 1997.
[RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP
Vendor Extensions", RFC 2132, March 1997.
[RFC2939] Droms, R., "Procedures and IANA Guidelines for
Definition of New DHCP Options and Message Types",
BCP 43, RFC 2939, September 2000.
[RFC3203] T'Joens, Y., Hublet, C., and P. De Schrijver, "DHCP
reconfigure extension", RFC 3203, December 2001.
[RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C. and M.
Carney, "Dynamic Host Configuration Protocol for IPv6",
July 2003.
[RFC6225] J. Polk., M. Linsner., M. Thomson., B. Aboba, Ed.,
"Dynamic Host Configuration Protocol Options for
Coordinate-Based Location Configuration Information",
July 2011.
[I-D.ietf-sfc-nsh]
Quinn, P. and U. Elzur, "Network Service Header", draft-
ietf-sfc-nsh-00 (work in progress), March 2015.
9.2 Informative References
Pal, et al. Expires Feb 16, 2017 [Page 11]
Internet-Draft DHCP option for NSH in SFP August 2016
[RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S.
Cheshire, "Internet Assigned Numbers Authority (IANA)
Procedures for the Management of the Service Name and
Transport Protocol Port Number Registry", BCP 165, RFC
6335, August 2011.
[RFC7348] Mahalingam, M., Dutt, D., Duda, K., Agarwal, P., Kreeger,
L., Sridhar, T., Bursell, M., and C. Wright, "Virtual
eXtensible Local Area Network (VXLAN): A Framework for
Overlaying Virtualized Layer 2 Networks over Layer 3
Networks", RFC 7348, August 2014.
[RFC7610] F. Gont, W. Liu, G. Van de Velde, "DHCPv6-Shield:
Protecting against Rogue DHCPv6 Servers", BCP 199,
August 2015
[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>.
[DHCP-OPTIONS]
Alexander, S. and R. Droms, "DHCP Options and
BOOTP Vendor Extensions", RFC 2132, March 1997.
[DHCP-IANA]
Droms, R., "Procedures and IANA Guidelines for
Definition of New DHCP Options and Message
Types", BCP 43, RFC 2939, September 2000.
[I-D.draft-ietf-sfc-control-plane-06]
Li, et al., "Service Function Chaining (SFC) Control Plane
Components & Requirements",
draft-ietf-sfc-control-plane-06 (work in progress),
May 2016.
Author's Address
Yogendra Pal
Cisco Systems, Inc.
Cessna Business Park,
Varthur Hobli, Outer Ring Road,
Bangalore, Karnataka 560103
India
EMail: yogpal@cisco.com
VenkataSubbaRao Gorrepati
Citrix R&D India Pvt Ltd,
Prestige Dynasty #33, Ulsoor Road
Bangalore, Karnataka 560042
India
EMail: venkatasubbarao.gorrepati@citrix.com
Vikram Menon
Ericsson India Global Services Pvt Ltd
Bangalore, Karnataka
India
EMail: vikram.menon@ericsson.com
