Internet DRAFT - draft-li-spring-srv6-span
draft-li-spring-srv6-span
Network Working Group Z. Li
Internet-Draft T. Sun
Intended status: Informational China Mobile
Expires: May 6, 2021 W. Cheng
J. Wang
Centec Networks
November 2, 2020
SRv6 SPAN
draft-li-spring-srv6-span-01
Abstract
As an important means for operation and maintenance (O&M), mirroring
is the most direct and comprehensive technology for capturing data
streams and forwarding information. Compared with other
visualization technologies, it can not only obtain the content of an
entire packet, but also add forwarding information of a network
device to a mirror packet and send the packet to a remote analysis
server.
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 .
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 May 6, 2021.
Li, et al. Expires May 6, 2021 [Page 1]
Internet-Draft SPRING Group November 2020
Copyright Notice
Copyright (c) 2020 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
(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 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. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Purposes for Proposing the SRv6 SPAN Technology . . . . . . . 3
2.1. Design and Implementation of the SRv6 SPAN Technology . . 4
2.1.1. SRv6 SPAN Technology and Networking . . . . . . . . . 4
2.1.2. SRv6 SPAN Technology and Packet Formats . . . . . . . 5
2.2. Future Considerations and Enhancements of the SRv6 SPAN
Technology . . . . . . . . . . . . . . . . . . . . . . . 8
3. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 9
4. Security Considerations . . . . . . . . . . . . . . . . . . . 9
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9
1. Introduction
The mirroring technology is also required in network O&M and fault
locating. Networking architectures and network scales vary with
scenarios, and accordingly requirements for mirroring technologies
are different. For example, port mirroring can meet mirroring
requirements for some small and medium-sized networks. In terms of
network architecture, on the physical link, a mirroring-enabled
switch is directly connected to a server used to analyze mirror
packets. Although it is simple to use the mirroring technology in
this case, the deployment of the mirror server is greatly limited.
With the expansion of the network scale, especially in a super-large
data center, the overlay tunneling technology is also used for
deploying the mirror server, so as to remove the limitation that the
mirror server needs to be directly connected on the physical link
during networking.
Li, et al. Expires May 6, 2021 [Page 2]
Internet-Draft SPRING Group November 2020
The conventional mirroring technology is designed and implemented
based on the IPv4 network, and data stream-based remote mirroring is
developed based on local port mirroring. Combined with the
networking in the data center, overlay and underlay networks are
connected using the GRE tunneling technology. As such, the analysis
server of mirror data packets can be flexibly deployed, and requires
only route reachability instead of direct connection on the physical
link.
In an SRv6 network, to simplify the network architecture and ensure
stable running, protocol types are reduced as much as possible. If
GRE is selected as the basic forwarding protocol of the mirroring
technology, more restrictions will be imposed on the application
scope of the mirroring technology. In addition, SRv6 is capable of
connecting overlay and underlay networks, and does not need any
additional forwarding protocol.
To better use the mirroring technology in the SRv6 network, a native
mirroring function needs to be designed based on the features of the
SRv6 network. Moreover, the formats of the conventional mirror
protocol packets and the existing device capabilities should be
reused to the maximum extent, so that the software system of the
existing mirror analysis server is compatible, thereby avoiding
redeveloping the software of the mirror server due to the SRv6-based
mirroring technology. This helps reduce the difficulty in
implementing the SRv6 network.
2. Purposes for Proposing the SRv6 SPAN Technology
Based on the IPv4 network technology, local port mirroring and data
stream-based remote mirroring are developed. In the networking of
the data center, the analysis server for mirror data packets should
have route reachability during deployment. Therefore, the
conventional far-end mirroring technology is based on GRE. There are
two reasons for using GRE: One is that packets encapsulated by GRE
support route-based forwarding, and only route reachability is
required for the deployment of the mirror analysis server in the data
center. Second, the large-scale construction of data centers
coincided with the introduction of the GRE technical standards in
2016 when Microsoft deployed GRE on a large scale in its data center.
Currently, two changes have taken place in the forwarding protocol
technology of the data center: One is that VXLAN, as an overlay
technology, exceeds GRE and is deployed in more data centers; the
other is that the IPv6 development has reached a critical moment, and
the SRv6 source routing technology based on the IPv6 data plane is
expected to be widely deployed in the future. Therefore, the GRE-
based mirroring technology deviates from the very-simple design
Li, et al. Expires May 6, 2021 [Page 3]
Internet-Draft SPRING Group November 2020
principle in a data center network architecture, and it is difficult
to use the GRE-based mirroring technology in a data center where
VXLAN has been deployed. Otherwise, the data plane and the control
plane will become more complex. In view of the above, this document
aims to design an SRv6 SPAN technology. On the one hand, it is born
to support the SRv6 network. SRv6 is capable of connecting overlay
and underlay networks and does not need IPv6 GRE, simplifying the
network architecture and protocols. On the other hand, the formats
of the conventional mirror protocol packets are reused to the maximum
extent, so that the software system of the existing mirror analysis
server is compatible, thereby avoiding redeveloping the software of
the mirror server due to the SRv6 SPAN technology. This helps reduce
the difficulty in implementing the SRv6 network.
2.1. Design and Implementation of the SRv6 SPAN Technology
This document aims to design an SRv6 SPAN technology, so as to: 1.
simplify the network architecture where the mirroring technology is
used and deployed; 2. be compatible with the packet formats of
conventional mirrors; 3. enhance the mirroring technology to meet new
requirements.
2.1.1. SRv6 SPAN Technology and Networking
SRv6 is used to connect overlay and underlay networks of mirror data
packets, without needing IPv6 GRE, thereby simplifying the network
architecture and protocols. However, the standard forwarding plane
of SRv6 may also be divided into two types: a standard SRv6 packet
carrying the SRH and a SRv6-BE packet carrying the SRH.
The SRv6 SPAN technology is designed to support SRv6-BE. This is
because IPv6 networks have been upgraded on a large scale, but the
SRv6 network is still under development. Different from standard
SRv6, SRv6-BE does not need to add the SRH but is directly borne on
the IPv6 tunnel, so that the SRv6/IPv6 network can use the mirroring
technology in this document to the maximum extent. Therefore, the
SRv6-BE mirroring technology only needs to support IPv6 forwarding,
which allows remote deployment of analysis servers for mirror
packets, while requires no SRv6 SRH processing capability. This
reduces the difficulty in deploying the SRv6 SPAN technology.
In addition, the SRv6 SPAN technology in this document further
supports the SRv6 network that carries the SRH. A network device
with SRv6 SRH processing capability can implement precise path
control by using a mirror packet encapsulated based on SRv6 SRH, and
can capture other forwarding information when the mirroring
technology is used.
Li, et al. Expires May 6, 2021 [Page 4]
Internet-Draft SPRING Group November 2020
Therefore, the SRv6 SPAN technology is not only compatible with a
device that supports only an IPv6 network, but also matches with a
network device with SRv6 SRH processing capability. It can remotely
deploy an analysis server used for mirror packets, implement path
control, and enable extensible forwarding information capturing.
2.1.2. SRv6 SPAN Technology and Packet Formats
The protocol packet formats of the SRv6 SPAN technology are
compatible with the formats of the conventional ERSPAN protocol
packet as far as possible. The formats of the conventional mirror
protocol packets are reused to the maximum extent, so that the
software system of the existing mirror analysis server is compatible,
thereby avoiding redeveloping the software of the mirror server.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Hdr=144 | Hdr Ext Len | Routing Type | Segments Left |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Last Entry | Flags | Tag |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Segment List[0] (128-bit IPv6 address) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| |
...
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Segment List[n] (128-bit IPv6 address) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| SRv6 SPAN Header |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Origin Packet |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
SRv6 SPAN Packet Format
Li, et al. Expires May 6, 2021 [Page 5]
Internet-Draft SPRING Group November 2020
Based on SRv6 packet formats, Next Header 144 is used to identify
SRv6 SPAN. In addition, the SRv6 SPAN Header format has been defined
in the first version of this document, and includes a 4-octet
sequence number and 12-octet portion forwarding information.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number (Increments per packet per session ) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ver | VLAN | COS |BSO|T| Session ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SGT |P| FT | Hw ID |D|Gra|O|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
SRv6 SPAN Header Format
The various fields of the above SRv6 SPAN header are described in
this table:
Field Length (bits) Definition
Sequence 32 For SRv6 SPAN packets sequence number，
number increased per packet per session，
for detecting loss of mirror packet
by analysis server.
Ver 4 SRv6 SPAN Encapsulation version.
For SRv6 SPAN packets it is set to 0x6.
VLAN 12 VLAN of the frame monitored by an SRv6 SPAN
source session: for ingress monitor this
will be the original source VLAN whereas
for egress monitor this will be the
destination VLAN.
COS 3 Class of Service of the monitored frame.
Ingress or egress CoS value is to be used
depending on the monitor type/direction.
T 1 This bit indicates that the frame copy
encapsulated in the SRv6 SPAN packet has
been truncated. This occurs if the SRv6 SPAN
encapsulated frame exceeds the configured
MTU and hence has to be truncated.
Li, et al. Expires May 6, 2021 [Page 6]
Internet-Draft SPRING Group November 2020
Session ID 10 Identification associated with each SRv6 SPAN
(ERSPAN ID) session. Must be unique between the source
and the receiver(s).
BSO (Bad/Short/ 2 A 2-bit value indicating the integrity of
Oversized) the payload carried by SRv6 SPAN:
00 --> Good frame with no error, or
unknown integrity
11 --> Payload is a Bad Frame with CRC or
Alignment Error
01 --> Payload is a Short Frame
10 --> Payload is an Oversized Frame
Timestamp 32 The timestamp value needs to be derived
from a hardware clock which is
synchronized to the system-clock. This 32-
bit field should support at least a
timestamp granularity of 100 microseconds
(see the Timestamp Granularity field).
SGT 16 Security Group Tag of the monitored frame.
P 1 This bit indicates that the SRv6 SPAN payload
is an Ethernet protocol frame .
FT (Frame Type) 5 This field can be used to reconstruct the
original frame's encapsulation if it is
supported by the receiver.
This field may also be used by SRv6 SPAN
engines to indicate that the mirrored
frame's L2 encapsulation header (or a
portion of it) was skipped and not
included in the SRv6 SPAN packet.
00000 --> Ethernet frame (802.3 frame)
00010 --> IP Packet
Other values --> Reserved for future use
Hw (Hardware) ID 6 Unique identifier of an SRv6 SPAN engine
within a system.
D (Direction) 1 Indicates whether the original frame was
SRv6 SPAN'ed in ingress or in egress.
Ingress (0) or Egress (1).
Gra (Timestamp
Granularity) 2 Time unit to be supported for time-
stamping:
00b --> granularity = 100 microseconds
Li, et al. Expires May 6, 2021 [Page 7]
Internet-Draft SPRING Group November 2020
01b --> granularity = 100 nanoseconds
10b --> granularity = IEEE 1588
TimeRepresentation format (see definition
below; with nanoseconds portion stored in
the Timestamp field and seconds portion
stored in the SRv6 SPAN platform-dependent
sub-header)
struct TimeRepresentation
{
UInteger32 seconds;
UInteger32 nanoseconds;
};
11b --> user configurable time unit
(platform dependent, for example specific
to an isolated non-synchronized system
with very high local accuracy)
O (Optional
Sub-header) 1 The O flag indicates whether or not the
optional platform-specific sub-header is
present. If it's present, the next octet
indicates the platform specific format
used (Platf ID). The SRv6 SPAN payload
starts after the O flag when O == 0b
or after 8 octets when O == 1b.
SRv6 SPAN Header Description
2.2. Future Considerations and Enhancements of the SRv6 SPAN Technology
In the first version of this document, the goal is to solve the
problem that the conventional mirroring technology is not compatible
with the existing SRv6 network.
In a later version of this document, the SRv6 SPAN technology will be
enhanced in three aspects:
* First, different requirements for mirroring capabilities in
multiple scenarios are met.
* Second, the capability of controlling a forwarding path and service
quality of a mirror data stream are enhanced;.
* Third, the capability of capturing required information is
enhanced.
Li, et al. Expires May 6, 2021 [Page 8]
Internet-Draft SPRING Group November 2020
SRv6 technology will be further developed, and enhancement points of
the SRv6 SPAN technology will be detailed in subsequent documents.
It is expected that the mirroring technology can be used as the
essential means for SRv6 network O&M and fault locating, so as to
facilitate the development of the SRv6 network.
3. Conclusion
The implementation of the SRv6 network mirroring function through
SRv6 SPAN technology is not only conducive to unifying the forwarding
data plane of the SRv6 network, avoiding the additional introduction
of GRE and other tunneling protocols, but also fully considering the
compatibility with the traditional mirroring message format in the
definition of SRv6 SPAN Header, Reduce the repeated development of
image analysis software to promote the development of SRv6 networks
and the deployment of SRv6 SPAN.
4. Security Considerations
TBD.
5. IANA Considerations
TBD.
Authors' Addresses
Zhiqiang Li
China Mobile
Beijing 100053
China
Email: lizhiqiangyjy@chinamobile.com
Tao Sun
China Mobile
Beijing 100053
China
Email: suntao@chinamobile.com
Li, et al. Expires May 6, 2021 [Page 9]
Internet-Draft SPRING Group November 2020
Wei Cheng
Centec Networks
Suzhou 215000
China
Email: chengw@centecnetworks.com
Junjie Wang
Centec Networks
Suzhou 21500
China
Email: wangjj@centecnetworks.com
Li, et al. Expires May 6, 2021 [Page 10]
