Skip to main content

6. Illustrations

6. Illustrations​

This section provides illustrations of SRv6 packet processing at SR source, transit, and SR segment endpoint nodes.

6.1. Abstract Representation of an SRH​

For a node k, its IPv6 address is represented as Ak, and its SRv6 SID is represented as Sk.

IPv6 headers are represented as the tuple of (source,destination). For example, a packet with source address A1 and destination address A2 is represented as (A1,A2). The payload of the packet is omitted.

An SR Policy is a list of segments. A list of segments is represented as <S1,S2,S3> where S1 is the first SID to visit, S2 is the second SID to visit, and S3 is the last SID to visit.

(SA,DA) (S3,S2,S1; SL) represents an IPv6 packet with:

  • Source Address SA, Destination Addresses DA, and next header SRH.
  • SRH with SID list <S1,S2,S3> with SegmentsLeft = SL.
  • Note the difference between the <> and () symbols. <S1,S2,S3> represents a SID list where the leftmost segment is the first segment. In contrast, (S3,S2,S1; SL) represents the same SID list but encoded in the SRH Segment List format where the leftmost segment is the last segment. When referring to an SR Policy in a high-level use case, it is simpler to use the <S1,S2,S3> notation. When referring to an illustration of detailed behavior, the (S3,S2,S1; SL) notation is more convenient.

At its SR Policy headend, the Segment List <S1,S2,S3> results in SRH (S3,S2,S1; SL=2) represented fully as:

Segments Left=2
Last Entry=2
Flags=0
Tag=0
Segment List[0]=S3
Segment List[1]=S2
Segment List[2]=S1

6.2. Example Topology​

The following topology is used in examples below:

+ * * * * * * * * * * * * * * * * * * * * +

*         [8]                [9]          *
           |                  |
*          |                  |           *
[1]----[3]--------[5]----------------[6]---------[4]---[2]
*          |                  |           *
           |                  |
*          |                  |           *
           +--------[7]-------+
*                                         *

+ * * * * * * *  SR domain  * * * * * * * +

                       Figure 1
  • 3 and 4 are SR domain edge routers
  • 5, 6, and 7 are all SR domain routers
  • 8 and 9 are hosts within the SR domain
  • 1 and 2 are hosts outside the SR domain
  • The SR domain implements ingress filtering as per Section 5.1 and no external packet can enter the domain with a destination address equal to a segment of the domain.

6.3. SR Source Node​

6.3.1. Intra-SR-Domain Packet​

When host 8 sends a packet to host 9 via an SR Policy <S7,A9> the packet is

P1: (A8,S7)(A9,S7; SL=1)

6.3.1.1. Reduced Variant​

When host 8 sends a packet to host 9 via an SR Policy <S7,A9> and it wants to use a reduced SRH, the packet is

P2: (A8,S7)(A9; SL=1)

6.3.2. Inter-SR-Domain Packet -- Transit​

When host 1 sends a packet to host 2, the packet is

P3: (A1,A2)

The SR domain ingress router 3 receives P3 and steers it to SR domain egress router 4 via an SR Policy <S7,S4>. Router 3 encapsulates the received packet P3 in an outer header with an SRH. The packet is

P4: (A3,S7)(S4,S7; SL=1)(A1,A2)

If the SR Policy contains only one segment (the egress router 4), the ingress router 3 encapsulates P3 into an outer header (A3,S4) without SRH. The packet is

P5: (A3,S4)(A1,A2)

6.3.2.1. Reduced Variant​

The SR domain ingress router 3 receives P3 and steers it to SR domain egress router 4 via an SR Policy <S7,S4>. If router 3 wants to use a reduced SRH, it encapsulates the received packet P3 in an outer header with a reduced SRH. The packet is

P6: (A3,S7)(S4; SL=1)(A1,A2)

6.3.3. Inter-SR-Domain Packet -- Internal to External​

When host 8 sends a packet to host 1, the packet is encapsulated for the portion of its journey within the SR domain. From 8 to 3 the packet is

P7: (A8,S3)(A8,A1)

In the opposite direction, the packet generated from 1 to 8 is

P8: (A1,A8)

At node 3, P8 is encapsulated for the portion of its journey within the SR domain, with the outer header destined to segment S8. This results in

P9: (A3,S8)(A1,A8)

At node 8, the outer IPv6 header is removed by S8 processing, then processed again when received by A8.

6.4. Transit Node​

Node 5 acts as transit node for packet P1 and sends packet

P1: (A8,S7)(A9,S7;SL=1)

on the interface toward node 7.

6.5. SR Segment Endpoint Node​

Node 7 receives packet P1 and, using the logic in Section 4.3.1, sends packet

P7: (A8,A9)(A9,S7; SL=0)

on the interface toward router 6.

6.6. Delegation of Function with HMAC Verification​

This section describes how a function may be delegated within the SR domain. In the following sections, consider a host 8 connected to a top of rack 5.

6.6.1. SID List Verification​

An operator may prefer to apply the SRH at source 8, while 5 verifies that the SID list is valid.

For illustration purposes, an SDN controller provides 8 an SRH terminating at node 9, with Segment List <S5,S7,S6,A9>, and HMAC TLV computed for the SRH. The HMAC key ID and key associated with the HMAC TLV is shared with 5. Node 8 does not know the key. Node 5 is configured with an IACL applied to the interface connected to 8, requiring HMAC verification for any packet destined to S/s.

Node 8 originates packets with the received SRH, including HMAC TLV.

P15: (A8,S5)(A9,S6,S7,S5;SL=3;HMAC)

Node 5 receives and verifies the HMAC for the SRH, then forwards the packet to the next segment

P16: (A8,S7)(A9,S6,S7,S5;SL=2;HMAC)

Node 6 receives

P17: (A8,S6)(A9,S6,S7,S5;SL=1;HMAC)

Node 9 receives

P18: (A8,A9)(A9,S6,S7,S5;SL=0;HMAC)

This use of an HMAC is particularly valuable within an enterprise-based SR domain [SRN].

Last updated on