Internet DRAFT - draft-nh-sr-hsfc-usecases-requirements
draft-nh-sr-hsfc-usecases-requirements
SPRING K. Ni, Ed.
Internet-Draft China Mobile
Intended status: Standards Track H. Huang, Ed.
Expires: 3 September 2024 Huawei
Y. Zhang
J. Ye, Ed.
China Mobile
2 March 2024
Problem Statement, Use Cases, and Requirements of Hierarchical SFC with
Segment Routing
draft-nh-sr-hsfc-usecases-requirements-01
Abstract
Hierarchical Service Function Chaining (hSFC) is a network service
chaining method that utilizes a hierarchical structure to efficiently
organize and manage service function chains, enhancing network
performance and scalability. This document primarily describes the
use case of hSFC, which is the security resource pool. It outlines
the associated problem statement and requirements for the security
resource pool. The document aims to assist in identifying candidate
solution architectures and solutions.
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 https://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 3 September 2024.
Copyright Notice
Copyright (c) 2024 IETF Trust and the persons identified as the
document authors. All rights reserved.
Ni, et al. Expires 3 September 2024 [Page 1]
Internet-Draft SR hSFC Usecases March 2024
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://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 to this document. Code Components
extracted from this document must include Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Requirements Language . . . . . . . . . . . . . . . . . . 4
2. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1. Problem Statement . . . . . . . . . . . . . . . . . . . . 5
2.1.1. Dispersion Of Service Resources . . . . . . . . . . . 5
2.1.2. Multi-tenant . . . . . . . . . . . . . . . . . . . . 5
2.1.3. Multi-vendor . . . . . . . . . . . . . . . . . . . . 6
2.1.4. Dynamic Orchestration . . . . . . . . . . . . . . . . 6
3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 6
4. Security Considerations . . . . . . . . . . . . . . . . . . . 7
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
6. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
6.1. Normative References . . . . . . . . . . . . . . . . . . 7
6.2. Informative References . . . . . . . . . . . . . . . . . 7
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 8
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8
1. Introduction
Service Function Chaining (SFC) [RFC7665] is a network service
delivery and traffic processing technique that allows for the
definition and execution of specific service chain routing policies,
ensuring that data flows through a sequence of service functions in a
predetermined order as it traverses the network. As network scales
have grown, such as the decentralization of service resources and the
diversification of tenants and vendors, it is difficult to
administrate such a large network. A new network architecture known
as Hierarchical Service Function Chaining (hSFC) [RFC8459] has
emerged. hSFC enables an organization to decompose large-scale
networks into multiple administrative domains. This means that it
can provide better network design, simplified control, and support
for different functional groups within the network, thereby enhancing
overall efficiency and management.
Ni, et al. Expires 3 September 2024 [Page 2]
Internet-Draft SR hSFC Usecases March 2024
To enhance network service security and offer a wide range of
protective services to users, network operators have centrally
constructed numerous security resource pools. Within these pools,
various security network devices, such as firewalls, Web Application
Firewalls (WAFs), Intrusion Prevention Systems (IPS), and more, are
deployed to deliver diverse value-added services (i.e Service
Function). According to tenants' business requirements or their
geographical location the user traffic is steered into the
corresponding security resource pool, after arriving which a series
of services in a certain order are provided based on security
protection needs, network topology, and resource usage. The packets
need to continue the remaining original forwardness when finishing
the processes inside the resource pool. As per [RFC8459], the
original path information before entering security resource pool is
expected to be stored somewhere, within the packets or in the gateway
of resource pools, so that it can be restored later. Therefore, it
is suitable to orchestrate with hSFC architecture. hSFC introduces a
solution based on NSH (Network Service Header). This approach
involves network configurations of each type of traffic and
additional NSH header in packet headers, which is complicated and not
conducive to expansive. However, in cases where SR (Segment Routing)
networks are deployed, it only needs to issue the SR policy to define
transmission path and update a new one to alter the path when
physical topology or business requirements change. By contrast, the
NSH solution may not be the preferred choice.
This document describes a use case involving the deployment of
multiple resource pools by network service provider. Every resource
pool is designed to offer tenants a wide range of security protection
services. The document also analyzes the challenges and issues
associated with this use case, discussing the requirements, seeking
an SR-based hSFC solution.
1.1. Terminology
hSFC: Hierarchical Service Function Chaining
NSH: Network Service Header
PBR: Policy Based Routing
SR: Segment Routing
SFC: Service Function Chaining
Ni, et al. Expires 3 September 2024 [Page 3]
Internet-Draft SR hSFC Usecases March 2024
1.2. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
2. Use Cases
To defend against network attacks, ensure the security of enterprise
tenants' business applications against viruses, malware, and other
security threats, and meet their customized security protection
needs, network operators have established security resource pools in
multiple regions. Typically, these security resource pools host
various security network devices, including firewalls, Web
Application Firewalls (WAF), Intrusion Prevention Systems (IPS), and
more, to provide a variety of security-focused value-added services.
In practical applications, the first step involves routing user
traffic to the appropriate security resource pool based on user
location, which typically utilizing SR in the existing Internet
environment. Then, customized security protection services are
provided to customers according to their specific requirements. For
example, some tenants may require the use of a firewall followed by
IPS services, while others may need to use IPS first and then utilize
firewall services. After traversing through all SFs in a SFC,
packets are returned to the gateway (i.e., security resource pool)
and continue to be forwarded to devices outside of IDC. This
necessitates hierarchical service chains to orchestrate SFs within
security resource pool (lower-level sub-domain)and service nodes
outside the IDC (upper-level domain) respectively and independently.
SR is a novel network orchestration technology that guides packet
paths by adding Segment Identifiers (Segment Routing) in the packet
header. Each Segment Identifier corresponds to a node or service
function within the network, creating an ordered path from source to
destination, defining the packet's transmission route. SR service
chain orchestration offers several advantages, including the
flexibility to define and customize service chain paths based on
specific application and business requirements, support for dynamic
adjustment of service chain paths based on real-time application
needs, and the ability to guide packets directly to the desired
service functions, reducing unnecessary delays within the service
chain. Furthermore, SR enables network administrators to manage
service chains without altering the underlying network topology,
simplifying network configuration.
Ni, et al. Expires 3 September 2024 [Page 4]
Internet-Draft SR hSFC Usecases March 2024
As a result, SR represents a user-friendly service chain
orchestration method suitable for complex network environments that
need to meet diverse application requirements. Given the complexity
of internet architecture, the widespread deployment of SR, and the
dynamic updates of security devices within a security resource pool,
it is recommended to use SR-based service chaining for traffic
steering within the security resource pool. This enables dynamic
adjustment of service chains and reduces traffic bypass.
2.1. Problem Statement
Due to the growth of network scales and the constraints of the
existing orchestration method, security resource pools is facing some
challenges of delivering value-added security protection services for
different users. This section provides an overview of these
challenges.
2.1.1. Dispersion Of Service Resources
Due to varying geographical locations of different tenants and for
the purpose of minimizing latency, facilitating network management,
and maintenance, the security resource pool is physically deployed in
a distributed manner.
2.1.2. Multi-tenant
In the existing Internet environment, tenants' network service
requirements have become diverse, with different tenants facing
various threats and demands. In the security resource pool, On one
hand, some tenants may only require basic access control
functionality, in which case, tenants would only need firewall
services. On the other hand, other tenants may necessitate more
complex and comprehensive security services. For instance, certain
tenants may require initial use of Web Application Firewall services
to isolate potential malicious websites and code, followed by
additional security checks using firewall services. Different
tenants have different needs, and the security resource pool needs to
provide tenant-level customized security protection capabilities.
Additionally, the network security device needs to be differentiated
between different tenants to provide them with distinct
configuration.
Ni, et al. Expires 3 September 2024 [Page 5]
Internet-Draft SR hSFC Usecases March 2024
2.1.3. Multi-vendor
In a security resource pool, security network devices are usually
provided by different vendors, they need to be orchestrated by
unified external network communication. For example, in the security
resource pool, firewalls are provided by Vendor A, and WAF is
provided by Vendor B. If a customer subscribes to both firewall and
WAF security value-added services, the traffic needs to pass through
Vendor A's firewall first and then through Vendor B's WAF device.
This implies that Vendor A's firewall needs to be aware of the next
hop being Vendor B's WAF device, and there is an expectation for the
traffic to flow directly from Vendor A's firewall device to Vendor
B's WAF.
2.1.4. Dynamic Orchestration
In a security resource pool, security network devices may encounter
dynamic adjustments. For example, adding new security network
devices to the pool may require existing service chains, such as NSH,
to undergo state updates across multiple devices. The main issue in
this situation is the presence of state (SPI, SI index tables) within
the network devices. Therefore, when there are changes in business
deployments, all network devices need to undergo state updates. This
is unfavorable for flexible and agile deployments. In contrast, SR
is friendly as it does not require the presence of specific states in
the network.
3. Requirements
[REQ-1] Tenant-level Service Orchestration
Different tenants have varying security protection needs.
specifically, the types and order of security protection they require
are differently. Therefore, it is imperative to cater to multiple
tenants and support tenant-level service chain orchestration.
[REQ-2] Tenant Information Carriage
As the security resource pool needs to meet service chaining at the
tenant level, it is essential for the packets to support carrying
tenant information.
[REQ-3] Dynamic Allocation Of Service Resources (Scalability)
Ni, et al. Expires 3 September 2024 [Page 6]
Internet-Draft SR hSFC Usecases March 2024
The security resource pool is in a constant state of dynamic
adjustment, and with the evolution of business needs, there may be
additions or removals of certain security network devices. When
there are updates to the security network devices within the resource
pool, it is essential to support their dynamic orchestration into the
service chain.
[REQ-4] Independent Resource Pool Orchestration
Service functions in different security resource pools support
different protocols (i.e., some security network devices within
certain resource pools do not support SR), and their suitable methods
for service chaining may also vary. Achieving unified orchestration
is challenging. Therefore, it is necessary for security resource
pools to support independent orchestration, without interfering with
each other.
[REQ-5] Reliability Of Service Function
During service chain orchestration, it is necessary to support the
retrieval of device information, including device operational status,
identification details, etc. In the event of network equipment
issues, bypassing the problematic equipment to avoid traffic
disruption should be enabled.
4. Security Considerations
TBD.
5. IANA Considerations
This document has no IANA actions.
6. References
6.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/rfc/rfc2119>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.
6.2. Informative References
Ni, et al. Expires 3 September 2024 [Page 7]
Internet-Draft SR hSFC Usecases March 2024
[RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function
Chaining (SFC) Architecture", RFC 7665,
DOI 10.17487/RFC7665, October 2015,
<https://www.rfc-editor.org/rfc/rfc7665>.
[RFC8459] Dolson, D., Homma, S., Lopez, D., and M. Boucadair,
"Hierarchical Service Function Chaining (hSFC)", RFC 8459,
DOI 10.17487/RFC8459, September 2018,
<https://www.rfc-editor.org/rfc/rfc8459>.
Acknowledgments
Contributors
Authors' Addresses
Kangkang Ni (editor)
China Mobile
Email: nikangkang@chinamobile.com
Hongyi Huang (editor)
Huawei
Email: hongyi.huang@huawei.com
Yige Zhang
China Mobile
Email: zhangyige@chinamobile.com
Jiaming Ye (editor)
China Mobile
Email: yejiaming@chinamobile.com
Ni, et al. Expires 3 September 2024 [Page 8]
