3.1.1. Cpipe Service Overview

Cpipe service is the Nokia implementation of TDM pseudowire VLL as defined in the IETF PWE3 working group.

The 7210 SAS devices can support TDM circuit applications that are able to transport delay sensitive TDM traffic over a packet network. For example, in case of business that use legacy T1/E1 interfaces, Cpipe services provide transport services. Cpipe services over MPLS tunnels are supported.

The TDM traffic is transported encapsulated in a TDM VLL over the packet switched network (PSN). The entire T1/E1 frame or part of a frame (n × 64 kb/s) is carried as a TDM VLL over the PSN. At the far end, the transport layer frame structure is regenerated when structured circuit emulation is used, or simply forwarded as part of the payload when unstructured circuit emulation is used.

3.1.2. Cpipe Service Modes

Cpipe services support unstructured circuit emulation mode (SAToP) as per RFC 4553, Structure-Agnostic Time Division Multiplexing (TDM) over Packet (SAToP), and structured circuit emulation mode (CESoPSN) for DS1, E1 and n × 64 kb/s circuits as per RFC 5086, Structure-Aware Time Division Multiplexed (TDM) Circuit Emulation Service over Packet Switched Network (CESoPSN).

3.1.2.1. Unstructured Mode (SAToP)

Structure-agnostic TDM over Packet (SAToP) is an unstructured circuit emulation mode used for the transport of unstructured TDM or structured TDM (where the structure is ignored).

Note: The word agnostic is used in RFC 4553, but it is not used in the literal sense. The meaning of agnostic in this case is unaware or independent. Therefore, structure-agnostic is used to mean structure-unaware or structure-independent.

As a structure-unaware or structure-independent service, SAToP service does not align to any framing; the framing mode for the port is set to unframed. For structured TDM, SAToP disregards the bit sequence and TDM structure to transport the entire signal over a PSN as a pseudowire.

3.1.2.2. Structured Mode (CESoPSN)

Structure-aware circuit emulation is used for the transport of structured TDM, taking at least some level of the structure into account. By selecting only the necessary n×64 kb/s timeslots to transport, bandwidth utilization is reduced or optimized (compared to a full DS1 or E1). Full DS1s or E1s can be transported by selecting all the timeslots in the DS1 or E1 circuit. Framing bits (DS1) or FAS (E1) are terminated at the near end and reproduced at the far end.

When CESoPSN with Channel Associated Signaling (CAS) is selected, the ABCD bits are coded into the T1 or E1 multi-frame packets, transported within the TDM PW, and reconstructed in the T1 or E1 multi-frame at the far end for each timeslot. CAS includes four signaling bits (A, B, C, and D) in the messages sent over a voice trunk. These messages provide information such as the dialed digits and the call state (whether on-hook or off-hook).

The mechanism for E1 CAS is described in ITU-T G.732. When configured for E1 CAS, timeslot 17 carries the signaling information for the timeslots used for voice trunking. Each channel requires four signaling bits, so grouping 16 E1 frames into a multi-frame allows the signaling bits for all 30 channels to be trunked.

As shown in Figure 15, timeslot 1 of all frames within the E1 multi-frame is reserved for alignment, alarm indication, and CRC. For Frame 0, timeslot 17 is reserved for multi-frame alignment bits. For the remaining 15 frames, timeslot 17 contains ABCD bits for two channels.

Note: For E1 CAS, timeslots are numbered 1 to 32 on the 7210 SAS.

For T1 CAS, the signaling bits are transferred using Robbed Bit Signaling (RBS), where the least significant bit in the channel is used periodically to transport these bits instead of voice data.

T1 CAS is supported when ESF or SF framing is configured. ESF framing uses a 24-frame multi-frame and transfers all four signaling bits (ABCD). SF framing uses a 12-frame multi-frame and transfers only the AB bits. The signaling bits are carried in the least significant bit of the following frames:

1. A bit in frame 6
2. B bit in frame 12
3. C bit in frame 18
4. D bit in frame 24

Figure 15:  E1 Framing for CAS Support in an E1 Multi-frame 

Table 32 describes the structure of a T1 ESF multi-frame that uses RBS. The structure of a T1 SF multi-frame is based on 12 frames and only the A and B bits are available.

Table 32:  T1 Framing for CAS (RBS) Support in a T1 ESF Multiframe 

Frame Number	F Bit				Bit Numbers in Each Channel Timeslot		Signaling Channel Designation  4
	Bit Number within Multiframe	Assignments
		FAS  1	DL  2	CRC  3	For Character Signal  4	For Signaling  4
1	1	—	m	—	1-8	—	—
2	194	—	—	e1	1-8	—	—
3	387	—	m	—	1-8	—	—
4	580	0	—	—	1-8	—	—
5	773	—	m	—	1-8	—	—
6	966	—	—	e2	1-7	8	A
7	1159	—	m	—	1-8	—	—
8	1352	0	—	—	1-8	—	—
9	1545	—	m	—	1-8	—	—
10	1738	—	—	e3	1-8	—	—
11	1931	—	m	—	1-8	—	—
12	2124	1	—	—	1-7	8	B
13	2317	—	m	—	1-8	—	—
14	2510	—	—	e4	1-8	—	—
15	2703	—	m	—	1-8	—	—
16	2896	0	—	—	1-8	—	—
17	3089	—	m	—	1-8	—	—
18	3282	—	—	e5	1-7	8	C
19	3475	—	m	—	1-8	—	—
20	3668	1	—	—	1-8	—	—
21	3861	—	m	—	1-8	—	—
22	4054	—	—	e6	1-8	—	—
23	4247	—	m	—	1-8	—	—
24	4440	1	—	—	1-7	8	D

Notes:

1. FAS = frame alignment signal (....001011.....)
2. DL = 4 kb/s data link (m represents message bits)
3. CRC = CRC-6 block check field (e1 to e6 represent check bits)
4. Only applicable for CAS

3.1.2.3. TDM Pseudowire Encapsulation

TDM circuits are MPLS-encapsulated as per RFC 4533 (SAToP) and RFC 5086 (CESoPSN), shown in Figure 16 and Figure 17.

Figure 16:  SAToP MPLS Encapsulation 

Figure 17:  CESoPSN MPLS Encapsulation 

Figure 18 shows the format of the CESoPSN TDM payload (with and without CAS) for packets carrying trunk-specific 64 kb/s service. In CESoPSN, the payload size is dependent on the number of timeslots used.

Figure 18:  CESoPSN Packet Payload Format for Trunk-Specific n x 64 kb/s (with and without CAS transport) 

For CESoPSN without CAS, select the packet size so that an integer number of frames are transported. That is, if n timeslots per frame are to be encapsulated in a TDM PW, then the packet size must be a multiple of n (where n is not equal to 1). For example, if n = 4 timeslots, then the packet size can be 8, 12, 16 and so on.

For CESoPSN with CAS, the packet size is an integer number of frames, where the number of frames is 24 for T1 or 16 for E1, and is not user-configurable. The extra bytes for ABCD (CAS) signaling bits are not included when setting the packet size.

Note: The extra bytes for CAS signaling bits must be included when setting the service-mtu size.

3.1.2.4. Circuit Emulation Parameters and Options

All ports on the T1/E1 ASAP Adapter card can be configured independently to support TDM circuit emulation across the packet network. Structure-aware mode (CESoPSN) is supported for n × 64 kb/s channel groups in DS1 and E1 circuits. Unstructured mode (SAToP) is supported for full DS1 and E1 circuits. The following parameters and options are described in this section:

1. Unstructured
2. Structured DS1/E1 CES without CAS
3. Structured T1/E1 CES with CAS
4. Packet Payload Size
5. Jitter Buffer
6. RTP Header
7. Control Word

3.1.2.4.1. Unstructured

Unstructured CES is configured by choosing satop-t1 or satop-e1 as the vc-type when creating a Cpipe service. For DS1 and E1 unstructured circuit emulation, the framing parameter of the port must be set to ds1-unframed and e1-unframed (respectively) because SAToP service ignores the underlying framing. Additionally, channel group 1 must contain all 24 or 32 timeslots, which is configured automatically when channel group 1 is created.

For DS1 and E1 circuit emulation, the payload packet size is configurable and must be an integer value between 64 and 1514 octets and must be a multiple of 32. The payload packet size affects the packet efficiency and packetization delay. Table 33 lists the default values for packet size and packetization delay.

Table 33:  Unstructured Payload Defaults  

Circuit	Payload Size (Octets)	Packetization Delay (milliseconds)
DS1	192	1.00
E1	256	1.00

Note: When using SAToP to transport DS1 traffic, the framing bit (bit 193) in the DS1 overhead is included and packed in the payload and sent over the PSN. If the underlying framing is ESF, then the Facility Data Link (FDL) channel is transported over the Cpipe as part of the SAToP service. No matter the case, the framing parameter of the port must be set to unframed.

3.1.2.4.2. Structured DS1/E1 CES without CAS

Structured CES without CAS is configured by choosing cesopsn as the vc-type when creating a Cpipe service. For n * 64 kb/s structured circuit emulation operation, the framing parameter of the port must be set to a framed setting (such as ESF for DS1). Each channel group contains n DS0s (timeslots), where n is between 1 and 24 timeslots for DS1 and between 1 and 31 timeslots for E1.

The packet payload size is configurable (in octets) and must be an integer multiple of the number of timeslots in the channel group. The minimum payload packet size is 2 octets (based on two frames per packet and one timeslot per frame). See Table 34 for default and minimum payload size values. The maximum payload packet size is 1514 octets.

Each DS1 or E1 frame contributes a number of octets to the packet payload. That number is equal to the number of timeslots configured in the channel group. Therefore, a channel group with four timeslots contributes 4 octets to the payload. The timeslots do not need to be contiguous.

Note that a smaller packet size results in a lower packetization delay; however, it increases the packet overhead (when expressed as a percentage of the traffic).

3.1.2.4.2.1. Calculation of Payload Size

The payload size (S), in octets, can be calculated using the following formula:

S = N x F

Where:

N = the number of octets (timeslots) collected per received frame (DS1 or E1)

F = the number of received frames (DS1 or E1) that are accumulated in each CESoPSN packet.

For example, assume the packet collects 16 frames (F) and the channel group contains 4 octets (timeslots) (N). Then the packet payload size (S) is:

S = 4 octets/frame x 16 frames

= 64 octets

3.1.2.4.2.2. Calculation of Packetization Delay

Packetization delay is the time needed to collect the payload for a CESoPSN packet. DS1 and E1 frames arrive at a rate of 8000 frames per second. Therefore, the received frame arrival period is 125 µs.

In the previous example, 16 frames were accumulated in the CESoPSN packet. In this case, the packetization delay (D) can be calculated as follows:

D = 125 µs/frame * 16 frames

= 2.000 ms

Table 34 lists the default and minimum values for frames per packet, payload size, and packetization delay as they apply to the number of timeslots (N) that contribute to the packet payload. The default values are set by the operating system as follows:

1. For N = 1, the default is 64 frames/packet
2. For 2 ≤ N ≤ 4, the default is 32 frames/packet
3. For 5 ≤ N ≤ 15, the default is 16 frames/packet
4. For N ≥ 16, the default is 8 frames/packet

Table 34:  Default and Minimum Payload Size for CESoPSN without CAS 

Number of Timeslots (N)	Default Values			Minimum Values
	Frames per Packet (F)	Payload Size (Octets) (S)	Packetization Delay (ms) (D)	Frames per Packet (F)	Payload Size (Octets) (S)	Packetization Delay (ms) (D)
1	64	64	8.000	2	2	0.250
2	32	64	4.000	2	4	0.250
3	32	96	4.000	2	6	0.250
4	32	128	4.000	2	8	0.250
5	16	80	2.000	2	10	0.250
6	16	96	2.000	2	12	0.250
7	16	112	2.000	2	14	0.250
8	16	128	2.000	2	16	0.250
9	16	144	2.000	2	18	0.250
10	16	160	2.000	2	20	0.250
11	16	176	2.000	2	22	0.250
12	16	192	2.000	2	24	0.250
13	16	208	2.000	2	26	0.250
14	16	224	2.000	2	28	0.250
15	16	240	2.000	2	30	0.250
16	8	128	1.000	2	32	0.250
17	8	136	1.000	2	34	0.250
18	8	144	1.000	2	36	0.250
19	8	152	1.000	2	38	0.250
20	8	160	1.000	2	40	0.250
21	8	168	1.000	2	42	0.250
22	8	176	1.000	2	44	0.250
23	8	184	1.000	2	46	0.250
24	8	192	1.000	2	48	0.250
25	8	200	1.000	2	50	0.250
26	8	208	1.000	2	52	0.250
27	8	216	1.000	2	54	0.250
28	8	224	1.000	2	56	0.250
29	8	232	1.000	2	58	0.250
30	8	240	1.000	2	60	0.250
31	8	248	1.000	2	62	0.250

3.1.2.4.3. Structured T1/E1 CES with CAS

Structured circuit emulation with CAS is supported for T1 and E1 circuits.

Structured CES with CAS service is configured by selecting cesopsn-cas as the vc-type when creating a Cpipe service. The DS1 or E1 service on the port associated with the Cpipe SAP should be configured to support CAS (using the signal-mode {cas} command) before configuring the Cpipe service to support DS1 or E1 with CAS. See the 7210 SAS-M, T, R6, R12, Mxp, Sx, S Interface Configuration Guide for information about configuring signal mode.

For n *64 kb/s structured circuit emulation with CAS, the implementation is almost identical to that of CES without CAS. When CAS operation is enabled, timeslot 16 cannot be included in the channel group on E1 carriers. The CAS option is enabled or disabled at the port level; therefore, it applies to all channel groups on that E1 port.

The packet size is based on 16 frames per packet for E1 when CAS is enabled and is not user-configurable. For example, if the number of timeslots is 4, then the payload size is 64 octets. This 16-frame fixed configuration is logical because an E1 multi-frame contains 16 frames; therefore, correct bit positioning for the A, B, C, and D CAS signaling bits can be ensured at each end of the pseudo wire.

Table 35 lists the payload sizes based on the number of timeslots.

For CAS, the signaling portion adds (n/2) bytes (n is an even integer) or ((n+1)/2) bytes (n is odd) to the packet, where n is the number of timeslots in the channel group. Note that you do not include the additional signaling bytes in the configuration setting of the TDM payload size. However, the operating system includes the additional bytes in the total packet payload, and the total payload must be accounted for when setting the service-mtu size. Continuing the preceding example, since n = 4, the total payload is 64 octets plus (4/2 = 2) CAS octets, or 66 octets. See Figure 18 to view the structure of the CES with CAS payload.

CES fragmentation is not supported.

Note: If you configure the service-mtu size to be smaller than the total payload size (payload plus CAS bytes), then the Cpipe will not become operational. This must be considered if you change the service-mtu from its default value.

Table 35 lists default values for the payload size for T1 and E1 CESoPSN with CAS.

Table 35:  Default Values for the Payload Size for T1 and E1 CESoPSN with CAS 

Number of Timeslots	T1			E1
	Number of Frames per Packet	Payload Size (Octets)	Packetization Delay (ms)	Number of Frames per Packet	Payload Size (Octets)	Packetization Delay (ms)
1	24	24	3.00	16	16	2.00
2	24	48	3.00	16	32	2.00
3	24	72	3.00	16	48	2.00
4	24	96	3.00	16	64	2.00
5	24	120	3.00	16	80	2.00
6	24	144	3.00	16	96	2.00
7	24	168	3.00	16	112	2.00
8	24	192	3.00	16	128	2.00
9	24	216	3.00	16	144	2.00
10	24	240	3.00	16	160	2.00
11	24	264	3.00	16	176	2.00
12	24	288	3.00	16	192	2.00
13	24	312	3.00	16	208	2.00
14	24	336	3.00	16	224	2.00
15	24	360	3.00	16	240	2.00
16	24	384	3.00	16	256	2.00
17	24	408	3.00	16	272	2.00
18	24	432	3.00	16	288	2.00
19	24	456	3.00	16	304	2.00
20	24	480	3.00	16	320	2.00
21	24	504	3.00	16	336	2.00
22	24	528	3.00	16	352	2.00
23	24	552	3.00	16	368	2.00
24	24	576	3.00	16	384	2.00
25	NA	NA	NA	16	400	2.00
26	NA	NA	NA	16	416	2.00
27	NA	NA	NA	16	432	2.00
28	NA	NA	NA	16	448	2.00
29	NA	NA	NA	16	464	2.00
30	NA	NA	NA	16	480	2.00

3.1.2.4.4. Packet Payload Size

The packet payload size defines the number of octets contained in the payload of a TDM pseudowire packet when the packet is transmitted. Each DS0 (timeslot) in a DS1 or E1 frame contributes 1 octet to the payload, and the total number of octets contributed per frame depends on the number of timeslots in the channel group (for example, 10 timeslots contribute 10 octets per frame).

3.1.2.4.5. Jitter Buffer

A circuit emulation service uses a jitter buffer to ensure that received packets are tolerant to packet delay variation (PDV). The selection of jitter buffer size must take into account the size of the TDM-encapsulated packets (payload size). A correctly configured jitter buffer provides continuous play-out, thereby avoiding discards due to overruns and under runs (packets arriving too early or too late). The maximum receive jitter buffer size is configurable for each SAP configured for circuit emulation. The range of values is from 1 to 250 ms in increments of 1 ms.

3.1.2.4.5.1. Configuration or Design Considerations

Determining the best configuration value for the jitter buffer may require some adjustments to account for the requirements of your network, which can change PDV as nodes are added or removed.

The buffer size must be set to at least three times the packetization delay and no greater than 32 times the packetization delay. Use a buffer size (in ms) that is equal to or greater than the peak-to-peak packet delay variation (PDV) expected in the network used by circuit emulation service. For example, for a PDV of ±5 ms, configure the jitter buffer to be at least 10 ms.

Note: The jitter buffer setting and payload size (packetization delay) interact such that it may be necessary for the operating system to adjust the jitter buffer setting to ensure no loss of packets. Therefore, the configured jitter buffer value may not be the value used by the system. Use the show>service>id service_id>all command to show the effective PDVT (packet delay variation tolerance).

The following values are the default jitter buffer times for structured circuits, where N is the number of timeslots:

1. For N = 1, the default is 32 ms
2. For 2 ≤ N ≤ 4, the default is 16 ms
3. For 5 ≤ N ≤ 15, the default is 8 ms
4. For N ≥ 16, the default is 5 ms

Jitter buffer overrun and under run counters are available for statistics and can raise an alarm (optional) while the circuit is operational. For overruns, excess packets are discarded and counted. For under runs, an all-ones pattern is sent for unstructured circuits and an all-ones or a user-defined pattern is sent for structured circuits (based on configuration).

The circuit status and statistics can be displayed using the appropriate show command.

3.1.2.4.6. RTP Header

For all circuit emulation channels, the RTP in the header is optional (as per RFC 5086).

When enabled for absolute mode operation, an RTP header is inserted in the MPLS frame upon transmit. Absolute mode is defined in RFC 5086 and means that the ingress PE will set timestamps using the clock recovered from the incoming TDM circuit. When an MPLS frame is received, the RTP header is ignored. The RTP header mode is for TDM pseudowire interoperability purposes only and should be enabled when the other device requires an RTP header.

3.1.2.4.7. Control Word

The structure of the control word is mandatory for SAToP and is shown in Figure 19.

Figure 19:  Control Word Bit Structure 

The control word descriptions are listed in Table 36.

Table 36:  Control Word Bit Description 

Bit(s)	Description
Bits 0 to 3	The use of bits 0 to 3 is described in RFC 4385. These bits are set to ‘0’ unless they are being used to indicate the start of an Associated Channel Header (ACH) for the purposes of VCCV.
L (Local TDM Failure)	The L bit is set to 1 if an abnormal condition of the attachment circuit such as LOS, LOF, or AIS has been detected and the TDM data carried in the payload is invalid. The L bit is cleared (set back to 0) when fault is rectified.
R (Remote Loss of Frames indication)	The R bit is set to 1 if the local CE-bound inter-working function (IWF) is in the packet loss state and cleared (reset to 0) after the local CE-bound IWF is no longer in the packet loss state.
M (Modifier)	The M bits are a 2-bit modifier field. For SAToP, M is set to 00 as per RFC 4553.
Sequence number	The sequence number is used to provide the common pseudowire sequencing function as well as detection of lost packets.

3.1.2.4.8. Error Situations

The CE-bound inter-working function (IWF) uses the sequence numbers in the control word to detect lost and incorrectly ordered packets. Incorrectly ordered packets that cannot be re-ordered are discarded.

For unstructured CES, the payload of received packets with the L bit set is replaced with an all-ones pattern. For structured CES, the payload of received packets with the L bit set is replaced with an all-ones or a user-configurable bit pattern. This is configured using the idle-payload-fill command. For structured CES with CAS, the signaling bits are replaced with an all-ones or a user-configurable bit pattern. This is configured using the idle-signal-fill command. See the 7210 SAS-M, T, R6, R12, Mxp, Sx, S Interface Configuration Guide more information. All circuit emulation services can have a status of up, loss of packets (LOP) or admin down, and any jitter buffer overruns or under runs are logged.

3.2.1. Epipe Service Overview

An Epipe service is a Layer 2 point-to-point service where the customer data is encapsulated and transported across a service provider network. An Epipe service is completely transparent to the subscriber data and protocols. The Epipe service does not perform any MAC learning. A local Epipe service consists of two SAPs on the same node, whereas a distributed Epipe service consists of two SAPs on different nodes.

Each SAP configuration includes a specific port on which service traffic enters the 7210 SAS router from the customer side (also called the access side). Each port is configured with an encapsulation type. If a port is configured with an IEEE 802.1Q (referred to as Dot1q) encapsulation, then a unique encapsulation value (ID) must be specified.

Figure 20 shows Epipe/VLL customer service.

Figure 20:  Epipe/VLL Service 

3.2.2. Epipe with PBB

Note: Epipes with PBB is only supported on 7210 SAS-M and 7210 SAS-T operating in the network mode.

A pbb-tunnel may be linked to an Epipe to a B-VPLS. MAC switching and learning is not required for the point-to-point service (all packets ingressing the SAP are PBB encapsulated and forwarded to the PBB tunnel to the backbone destination MAC address and all the packets ingressing the B-VPLS destined for the ISID are PBB de-encapsulated and forwarded to the Epipe SAP. A fully specified backbone destination address must be provisioned for each PBB Epipe instance to be used for each incoming frame on the related I-SAP. If the backbone destination address is not found in the B-VPLS FDB then packets may be flooded through the B-VPLSes

All B-VPLS constructs may be used including B-VPLS resiliency and OAM. Not all generic Epipe commands are applicable when using a PBB tunnel.

3.2.3. Support for Processing of Packets Received with More Than 2 Tags on a QinQ SAP in Epipe Service

Note: This section applies to all 7210 SAS platforms as described in this document, except those operating in access-uplink mode. 7210 SAS platforms operating in access-uplink mode can process and forward packets with more than two tags. See Configuration Notes for restrictions on the use of SAPs by platforms operating in access-uplink mode.

To forward packets with 2 or more tags using a QinQ SAP, a new Epipe service type is available for use when 7210 SAS devices are operating in ‘network’ mode. This new service will allow for configuration of a QinQ SAP as one endpoint and the following service entities as the other endpoint:

The device will process the packet as listed as follows in the forward direction:

In the reverse direction, the device will process the packet as listed as follows:

Therefore, the device processes packets received with 2 or more tags using the MPLS SDP or a dot1q SAP while classifying on the QinQ SAP ingress using 2 tags.

3.2.4. Epipe Operational State Decoupling

An Epipe service transitions to an operation state, ‘Down’ when only a single entity SAP or Binding is active and the operation state of the mate is down or displays an equivalent state. The default behavior does not allow operators to validate the connectivity and measure performance metrics. With this feature an option is provided to allow operators to validate the connectivity and measure performance metrics of an Epipe service before the customer handoff. The operator can also maintain performance and continuity measurement across their network regardless of the connectivity between the terminating node and the customer. If the SAP between the operator and the customer enters a Oper Down state, the Epipe remains Operationally UP, so the results can continue to be collected uninterrupted. The operator receives applicable port or SAP alerts/alarms. This option is available only for the customer facing SAP failures. If a network facing SAP or Spoke-SDP fails the operational state of the Epipe service is set to 'Down'. That is, there is no option to hold the service in an UP state, if a network component fails.

The following functionality is supported:

3.3.1. Pseudowire Switching with Protection

Pseudowire switching scales VLL and VPLS services over a multi-area network by removing the need for a full mesh of targeted LDP sessions between PE nodes. Figure 21 shows the use of pseudowire redundancy to provide a scalable and resilient VLL service across multiple IGP areas in a provider network.

Figure 21:  VLL Resilience with Pseudowire Redundancy and Switching 

In the network in Figure 21, PE nodes act as masters and pseudowire switching nodes act as slaves for the purpose of pseudowire signaling. A switching node will need to pass the SAP Interface Parameters of each PE to the other.T-PE1 sends a label mapping message for the Layer 2 FEC to the peer pseudowire switching node” for example, S-PE1. It will include the SAP interface parameters, such as MTU, in the label mapping message. S-PE1 checks the FEC against the local information and if a match exists, it appends the optional pseudowire switching point TLV to the FEC TLV in which it records its system address. T-PE1 then relays the label mapping message to S-PE2. S-PE2 performs similar operations and forwards a label mapping message to T-PE2. The same procedures are followed for the label mapping message in the reverse direction, for example, from T-PE2 to T-PE1. S-PE1 and S-PE2 will effect the spoke-SDP cross-connect only when both directions of the pseudowire have been signaled and matched.

The pseudowire switching TLV is useful in a few situations. First, it allows for troubleshooting of the path of the pseudowire especially if multiple pseudowire switching points exist between the two T-PE nodes. Secondly, it helps in loop detection of the T-LDP signaling messages where a switching point receives back a label mapping message it already relayed. Finally, it can be inserted in pseudowire status messages when they are sent from a pseudowire switching node toward a destination PE.

Pseudowire status messages can be generated by the T-PE nodes. Pseudowire status messages received by a switching node are processed and then passed on to the next hop. An S-PE node appends the optional pseudowire switching TLV, with its system address added to it, to the FEC in the pseudowire status notification message only if it originated the message or the message was received with the TLV in it. Otherwise, it means the message was originated by a T-PE node and the S-PE should process and pass the message without changes except for the VCID value in the FEC TLV.

3.3.2. Pseudowire Switching Behavior

In the network in Figure 21, PE nodes act as masters and pseudowire switching nodes act as slaves for the purpose of pseudowire signaling. This is because a switching node will need to pass the SAP interface parameters of each PE to the other.T-PE1 sends a label mapping message for the Layer 2 FEC to the peer pseudowire switching node, for example, S-PE1. It will include the SAP interface parameters, such as MTU, in the label mapping message. S-PE1 checks the FEC against the local information and if a match exists, it appends the optional pseudowire switching point TLV to the FEC TLV in which it records its system address. T-PE1 then relays the label mapping message to S-PE2. S-PE2 performs similar operation and forwards a label mapping message to T-PE2. The same procedures are followed for the label mapping message in the reverse direction, for example, from T-PE2 to T-PE1. S-PE1 and S-PE2 will effect the spoke-SDP cross-connect only when both directions of the pseudowire have been signaled and matched.

The merging of the received T-LDP status notification message and the local status for the spoke-SDPs from the service manager at a PE complies with the following rules:

3.3.2.1. Pseudowire Switching TLV

Figure 22 shows the format of the pseudowire switching TLV.

Figure 22:  Pseudowire Switching TLV Format 

1. PW sw TLV Length
   This field specifies the total length of all the following pseudowire switching point TLV fields in octets.
2. Type
   This field encodes how the Value field is interpreted.
3. Length
   This field specifies the length of the Value field in octets.
4. Value
   The Octet string of Length octets encodes information to be interpreted as specified by the Type field.

The format of the pseudowire switching point sub-TLVs is as follows:

1. pseudowire ID of last pseudowire segment traversed
   This sub-TLV type contains a pseudowire ID in the format of the pseudowire ID.
2. pseudowire switching point description string
   This is an optional description text string up to 80 characters.
3. IP address of pseudowire switching point
4. IPv4 or IPv6 address of pseudowire switching point
   This is an optional sub-TLV.
5. MH VCCV capability indication

3.3.3. Pseudowire Redundancy

Pseudowire redundancy provides the ability to protect a pseudowire with a preprovisioned pseudowire and to switch traffic over to the secondary standby pseudowire in case of a SAP and/or network failure condition. Usually, pseudowires are redundant by the virtue of the SDP redundancy mechanism. For instance, if the SDP is an RSVP LSP and is protected by a secondary standby path and/or by Fast-Reroute paths, the pseudowire is also protected. However, there are a couple of applications in which SDP redundancy does not protect the end-to-end pseudowire path:

Pseudowire and VPLS link redundancy extends link-level resiliency for pseudowires and VPLS to protect critical network paths against physical link or node failures. These innovations enable the virtualization of redundant paths across the metro or core IP network to provide seamless and transparent fail-over for point-to-point and multi-point connections and services. When deployed with multi-chassis LAG, the path for return traffic is maintained through the pseudowire or VPLS switchover, which enables carriers to deliver “always on” services across their IP/MPLS networks.

3.3.3.1. VLL Resilience with Two Destination PE Nodes

Figure 23 shows the application of pseudowire redundancy to provide Ethernet VLL service resilience for broadband service subscribers accessing the broadband service on the service provider BRAS.

Figure 23:  VLL Resilience 

If the Ethernet SAP on PE2 fails, PE2 notifies PE1 of the failure by either withdrawing the primary pseudowire label it advertised or by sending a pseudowire status notification with the code set to indicate a SAP defect. PE1 will receive it and will immediately switch its local SAP to forward over the secondary standby spoke-SDP. To avoid black holing of in-flight packets during the switching of the path, PE1 will accept packets received from PE2 on the primary pseudowire while transmitting over the backup pseudowire.

When the SAP at PE2 is restored, PE2 updates the new status of the SAP by sending a new label mapping message for the same pseudowire FEC or by sending pseudowire status notification message indicating that the SAP is back up. PE1 then starts a timer and reverts back to the primary at the expiry of the timer. By default, the timer is set to 0, which means PE1 reverts immediately. A special value of the timer (infinity) will mean that PE1 should never revert back to the primary pseudowire.

The behavior of the pseudowire redundancy feature is the same if PE1 detects or is notified of a network failure that brought the spoke-SDP operational status to DOWN. The following are the events which will cause PE1 to trigger a switchover to the secondary standby pseudowire:

1. T-LDP peer (remote PE) node withdrew the pseudowire label.
2. T-LDP peer signaled a FEC status indicating a pseudowire failure or a remote SAP failure.
3. T-LDP session to peer node times out.
4. SDP binding and VLL service went down as a result of network failure condition such as the SDP to peer node going operationally down.

The 7210 SAS routers support the ability to configure multiple secondary standby pseudowire paths. For example, PE1 uses the value of the user configurable precedence parameter associated with each spoke-SDP to select the next available pseudowire path after the failure of the current active pseudowire (whether it is the primary or one of the secondary pseudowires). The revertive operation always switches the path of the VLL back to the primary pseudowire though. There is no revertive operation between secondary paths meaning that the path of the VLL will not be switched back to a secondary pseudowire of higher precedence when the latter comes back up again.

-The 7210 SAS routers support the ability for a user-initiated manual switchover of the VLL path to the primary or any of the secondary be supported to divert user traffic in case of a planned outage such as in node upgrade procedures.

3.3.4. Dynamic Multi-Segment Pseudowire Routing

Note: T-PE functionality is supported on all 7210 SAS platforms as described in this document, except those operating in access-uplink mode. S-PE functionality is only supported on 7210 SAS-Mxp, 7210 SAS-Sx/S 1/10GE, and 7210 SAS-Sx 10/100GE. The following sections describe the end-to-end solution with BGP PW-routing, assuming appropriate platforms are used for various functions.

Dynamic Multi-Segment Pseudowire Routing (Dynamic MS-PWs) enable a complete multi-segment pseudowire to be established, while only requiring per-pseudowire configuration on the T-PEs. No per-pseudowire configuration is required on the S-PEs. End-to-end signaling of the MS-PW is achieved using T-LDP, while multi-protocol BGP is used to advertise the T-PEs, so allowing dynamic routing of the MS-PW through the intervening network of S-PEs. Dynamic multi-segment pseudowires are described in the IETF in draft-ietf-pwe3-dynamic-ms-pw-13.txt.

Figure 24 shows the operation of dynamic MS-PWs.

Figure 24:  Dynamic MS-PW Overview 

The FEC 129 AII Type 2 structure shown in Figure 25 is used to identify each individual pseudowire endpoint:

Figure 25:  Figure 2 MS-PW Addressing using FEC129 AII Type 2 

A 4-byte global ID followed by a 4 byte prefix and a 4 byte attachment circuit ID are used to provide for hierarchical, independent allocation of addresses on a per service provider network basis. The first 8 bytes (Global ID + Prefix) may be used to identify each individual T-PE or S-PE as a loopback Layer 2 Address.

This new AII type is mapped into the MS-PW BGP NLRI (a new BGP AFI of L2VPN, and SAFI for network layer reachability information for dynamic MS-PWs. As soon as a new T- PE is configured with a local prefix address of global id:prefix, pseudowire routing will proceed to advertise this new address to all the other T- PEs and S-PEs in the network, as shown in Figure 26.

Figure 26:  Advertisement of PE Addresses by PW Routing 

In step 1 a new T-PE (T-PE2) is configured with a local prefix.

Next, in steps 2-5, MP-BGP will use the NLRI for the MS-PW routing SAFI to advertise the location of the new T-PE to all the other PEs in the network. Alternatively, static routes may be configured on a per T-PE/S-PE basis to accommodate non-BGP PEs in the solution.

As a result, pseudowire routing tables for all the S-PEs and remote T-PEs are populated with the next hop to be used to reach T-PE2.

VLL services can then be established, as shown in Figure 27.

Figure 27:  Signaling of Dynamic MS-PWs using T-LDP 

In step 1 and 1' the T-PEs are configured with the local and remote endpoint information, Source AII (SAII), Target AII (TAII). On the 7210, the AIIs are locally configured for each spoke-SDP, according to the model shown in Figure 28. The 7210 therefore provides for a flexible mapping of AII to SAP. That is, the values used for the AII are through local configuration, and it is the context of the spoke-SDP that binds it to a specific SAP.

Figure 28:  Mapping of AII to SAP 

Before T-LDP signaling starts, the two T-PEs decide on an active and passive relationship using the highest AII (comparing the configured SAII and TAII) or the configured precedence. Next, the active T-PE (in the IETF draft this is referred to as the source T-PE or ST-PE) checks the PW Routing Table to determine the next signaling hop for the configured TAII using the longest match between the TAII and the entries in the PW routing table

This signaling hop is then used to choose the T-LDP session to the chosen next-hop S-PE. Signaling proceeds through each subsequent S-PE using similar matching procedures to determine the next signaling hop. Otherwise, if a subsequent S-PE does not support dynamic MS-PW routing and therefore uses a statically configured PW segment, the signaling of individual segments follows the procedures already implemented in the PW Switching feature. Note that BGP can install a PW AII route in the PW routing table with ECMP next-hops. However when LDP needs to signal a PW with matching TAII, it will choose only one next-hop from the available ECMP next-hops. PW routing supports up to 4 ECMP paths for each destination.

The signaling of the forward path ends when the PE matches the TAII in the label mapping message with the SAII of a spoke-SDP bound to a local SAP. The signaling in the reverse direction can now be initiated, which follows the entries installed in the forward path. The PW Routing tables are not consulted for the reverse path. This ensures that the reverse direction of the PW follows exactly the same set of S-PEs as the forward direction.

This solution can be used in either a MAN-WAN environment or in an Inter-AS/Inter-Provider environment as shown in Figure 29.

Figure 29:  VLL Using Dynamic MS-PWs, Inter-AS Scenario 

Note that data plane forwarding at the S-PEs uses pseudowire service label switching, as per the pseudowire switching feature.

3.3.4.3. Pseudowire Redundancy

Pseudowire redundancy is supported on dynamic MS-PWs used for VLLs. It is configured in a similar manner to pseudowire redundancy on VLLs using FEC128, whereby each spoke-sdp-fec within an endpoint is configured with a unique SAII/TAII.

Figure 30 shows the use of pseudowire redundancy.

Figure 30:  Pseudowire Redundancy 

The following is a summary of the key points to consider in using pseudowire redundancy with dynamic MS-PWs:

1. Each MS-PW in the redundant set must have a unique SAII/TAII set and is signaled separately. The primary pseudowire is configured in the spoke-sdp-fec>primary context.
2. Each MS-PW in the redundant set should use a diverse path (from the point of view of the S-PEs traversed) from every other MS-PW in that set if path diversity is possible in a specific network topology. There are a number of possible ways to achieve this:
   1. Configure an explicit path for each MS-PW.
   2. Allow BGP routing to automatically determine diverse paths using BGP policies applied to different local prefixes assigned to the primary and standby MS-PWs.
   3. Path diversity can be further provided for each primary pseudowire through the use of a BGP route distinguisher.

If the primary MS-PW fails, fail-over to a standby MS-PW, as per the normal pseudowire redundancy procedures. A configurable retry timer for the failed primary MS-PW is then started. When the timer expires, attempt to reestablish the primary MS-PW using its original path, up to a maximum number of attempts as per the retry count parameter. The T-PE may then optionally revert back to the primary MS-PW on successful reestablishment.

Note that since the SDP ID is determined dynamically at signaling time, it cannot be used as a tie breaker to choose the primary MS-PW between multiple MS-PWs of the same precedence. The user should therefore explicitly configure the precedence values to determine which MS-PW is active in the final selection.

3.3.5. Example Dynamic MS-PW Configuration

Figure 31 shows how to configure Dynamic MS-PWs for a VLL service between a set of 7210 nodes. The network consists of two 7210 T-PEs and two 7210s in the role of S-PEs. Each 7210 peers with its neighbor using LDP and BGP.

Figure 31:  Dynamic MS-PW Example 

The example uses BGP to route dynamic MS-PWs and T-LDP to signal them. Therefore each node must be configured to support the MS-PW address family under BGP, and BGP and LDP peerings must be established between the T-PEs/S-PEs. The appropriate BGP export policies must also be configured.

Next, pseudowire routing must be configured on each node. This includes an S-PE address for every participating node, and one or more local prefixes on the T-PEs. MS-PW paths and static routes may also be configured. When this routing and signaling infrastructure is established, spoke-sdp-fecs can be configured on each of the T-PEs.

T-PE-1

T-PE-2

S-PE-1

S-PE-2

3.4.1. Operation of Master-Slave Pseudowire Redundancy with Existing Scenarios

This section illustrates how master-slave pseudowire redundancy could operate.

3.4.1.1. VLL Resilience

Figure 33 shows a VLL resilience path example. An sample configuration follows.

Figure 33:  VLL Resilience 

Note that a revert-time value of zero (default) means that the VLL path will be switched back to the primary immediately after it comes back up

PE1

configure service epipe 1

     endpoint X

     exit

     endpoint Y

     revert-time 0

     standby-signaling-master

     exit

     sap 1/1/1:100 endpoint X

     spoke-sdp 1:100 endpoint Y 

precedence primary

     spoke-sdp 2:200 endpoint Y 

precedence 1

PE2

configure service epipe 1

     endpoint X

     exit

     sap 2/2/2:200 endpoint X

     spoke-sdp 1:100 

          standby-signaling-slave

 

PE3

configure service epipe 1

     endpoint X

     exit

     sap 3/3/3:300 endpoint X

     spoke-sdp 2:200 

          standby-signaling-slave

3.4.2. VLL Resilience for a Switched PW Path

Note: T-PE functionality is supported on all 7210 SAS platforms as described in this document, except those operating in access-uplink mode. S-PE functionality is only supported on 7210 SAS-Mxp, 7210 SAS-Sx/S 1/10GE, and 7210 SAS-Sx 10/100GE.

Figure 34 shows a VLL resilience for a switched pseudowire path example. A sample configuration follows.

Figure 34:  VLL Resilience with Pseudowire Switching 

S-PE1

VC switching indicates a VC cross-connect so that the service manager does not signal the VC label mapping immediately but will put this into passive mode.

3.4.3. Access Node Resilience Using MC-LAG and Pseudowire Redundancy

Figure 35 shows the use of both Multi-Chassis Link Aggregation (MC-LAG) in the access network and pseudowire redundancy in the core network to provide a resilient end-to-end VLL service to the customers.

Figure 35:  Access Node Resilience 

In this application, a new pseudowire status bit of active or standby indicates the status of the SAP in the MC-LAG instance in the 7210 SAS aggregation node. All spoke-SDPs are of secondary type and there is no use of a primary pseudowire type in this mode of operation. Node A is in the active state according to its local MC-LAG instance and therefore advertises active status notification messages to both its peer pseudowire nodes, for example, nodes C and D. Node D performs the same operation. Node B is in the standby state according to the status of the SAP in its local MC-LAG instance and therefore advertises standby status notification messages to both nodes C and D. Node C performs the same operation.

7210 SAS node selects a pseudowire as the active path for forwarding packets when both the local pseudowire status and the received remote pseudowire status indicate active status. However, a 7210 SAS device in standby status according to the SAP in its local MC-LAG instance is capable of processing packets for a VLL service received over any of the pseudowires which are up. This is to avoid black holing of user traffic during transitions. The 7210 SAS standby node forwards these packets to the active node bye the Inter-Chassis Backup pseudowire (ICB pseudowire) for this VLL service. An ICB is a spoke-SDP used by a MC-LAG node to backup a MC-LAG SAP during transitions. The same ICB can also be used by the peer MC-LAG node to protect against network failures causing the active pseudowire to go down.

Note that at configuration time, the user specifies a precedence parameter for each of the pseudowires which are part of the redundancy set as described in the application. A 7210 SAS node uses this to select which pseudowire to forward packet to in case both pseudowires show active/active for the local/remote status during transitions.

Only VLL service of type Epipe is supported in this application. Also, ICB spoke-SDP can only be added to the SAP side of the VLL cross-connect if the SAP is configured on a MC-LAG instance.

3.4.4. VLL Resilience for a Switched Pseudowire Path

Figure 36 shows the use of both pseudowire redundancy and pseudowire switching to provide a resilient VLL service across multiple IGP areas in a provider network.

Figure 36:  VLL Resilience with Pseudowire Redundancy and Switching 

Pseudowire switching is a method for scaling a large network of VLL or VPLS services by removing the need for a full mesh of T-LDP sessions between the PE nodes as the number of these nodes grows over time.

Like in the application in VLL Resilience for a Switched Pseudowire Path, the T-PE1 node switches the path of a VLL to a secondary standby pseudowire in the case of a network side failure causing the VLL binding status to be DOWN or if T-PE2 notified it that the remote SAP went down. This application requires that pseudowire status notification messages generated by either a T-PE node or a S-PE node be processed and relayed by the S-PE nodes.

Note that it is possible that the secondary pseudowire path terminates on the same target PE as the primary, for example, T-PE2. This provides protection against network side failures but not against a remote SAP failure. When the target destination PE for the primary and secondary pseudowires is the same, T-PE1 will usually not switch the VLL path onto the secondary pseudowire upon receipt of a pseudowire status notification indicating the remote SAP is down since the status notification is sent over both the primary and secondary pseudowires. However, the status notification on the primary pseudowire may arrive earlier than the one on the secondary pseudowire due to the differential delay between the paths. This will cause T-PE1 to switch the path of the VLL to the secondary standby pseudowire and remain there until the status notification is cleared. At that point in time, the VLL path is switched back to the primary pseudowire due to the revertive behavior operation. The path will not switch back to a secondary path when it becomes up even if it has a higher precedence than the currently active secondary path.

3.5.1. Redundant VLL Service Model

To implement pseudowire redundancy, a VLL service accommodates more than a single object on the SAP side and on the spoke-SDP side. Figure 37 shows the model for a redundant VLL service based on the concept of endpoints.

Figure 37:  Redundant VLL Endpoint Objects 

A VLL service supports by default two implicit endpoints managed internally by the system. Each endpoint can only have one object, a SAP or a spoke-SDP.

To add more objects, up to two (2) explicitly named endpoints may be created per VLL service. The endpoint name is locally significant to the VLL service. They are referred to as endpoint 'X' and endpoint 'Y' as illustrated in Figure 37.

Note that Figure 37 is merely an example and that the “Y” endpoint can also have a SAP and/or an ICB spoke-SDP. The following details the four types of endpoint objects supported and the rules used when associating them with an endpoint of a VLL service:

A VLL service endpoint can only use a single active object to transmit at any time but can receive from all endpoint objects

An explicitly named endpoint can have a maximum of one SAP and one ICB. When a SAP is added to the endpoint, only one more object of type ICB spoke-SDP is allowed. The ICB spoke-SDP cannot be added to the endpoint if the SAP is not part of a MC-LAG instance. Conversely, a SAP which is not part of a MC-LAG instance cannot be added to an endpoint which already has an ICB spoke-SDP.

An explicitly named endpoint, which does not have a SAP object, can have a maximum of four spoke-SDPs and can include any of the following:

3.5.2. T-LDP Status Notification Handling Rules

Referring to Redundant VLL Endpoint Objects as a reference, the following are the rules for generating, processing, and merging T-LDP status notifications in VLL service with endpoints. Note that any allowed combination of objects as specified in Redundant VLL Service Model can be used on endpoints “X” and “Y”. The following sections refer to the specific combination objects in Figure 37 as an example to describe the more general rules.

3.6.1. SDPs

An SDP used for MPLS-TP supports the configuration of an MPLS-TP identifier as the far end address, as an alternative to an IP address. IP addresses are used if IP/MPLS LSPs are used by the SDP, or MPLS-TP tunnels identified by IPv4 source or destination addresses. MPLS-TP node identifiers are used if MPLS-TP tunnels are used.

The following syntax shows the new MPLS-TP options.

The far-end node-id <ip-address> global-id <global-id> command is used to associate an SDP far end with an MPLS-TP tunnel whose far end address is an MPLS-TP node ID. If the SDP is associated with an RSVP-TE LSP, then the far-end must be a routable IPv4 address.

The system accepts the node-id being entered as either 4-octet IP address format <a.b.c.d> or unsigned integer format.

The SDP far-end refer to an MPLS-TP node-id or global-id only if:

An LSP will only be allowed to be configured if the far-end info matches the LSP far-end info (whether MPLS-TP or RSVP).

Signaling TLDP or BGP is blocked if:

The following commands are blocked if a far-end node-id or global-id is configured:

3.6.2. VLL Spoke-SDP Configuration

7210 SAS-T can only be a T-PE. MPLS-TP OAM related commands are applicable to spoke-SDPs configured under all services supported by MPLS-TP pseudowires. All commands and functions that are applicable to spoke-SDPs in the current implementation are supported, except for those that explicitly depend on an LDP session on the SDP or as stated as follows. Likewise, all existing functions on a specific service SAP are supported if the spoke-SDPs that it is matched to is MPLS-TP.

The following describes how to configure MPLS-TP on an Epipe VLL. However, similar configuration applies to other VLL types.

A spoke-SDP bound to an SDP with the mpls-tp keyword cannot be no shutdown unless the ingress label, the egress label, the control word, and the pw-path-id are configured.

The pw-path-id context is used to configure the end-to-end identifiers for a MS-PW. These may not coincide with those for the local node if the configuration is at an S-PE. The saii and taii are consistent with the source and destination of a label mapping message for a signaled PW.

The control-channel-status command enables static PW status signaling. This is valid for any spoke-sdp where signaling none is configured on the SDP (for example, where T-LDP signaling is not in use). The refresh timer is specified in seconds, from 10-65535, with a default of 0 (off). This value can only be changed if control-channel-status is shutdown. Commands that rely on PW status signaling are allowed if control-channel-status is configured for a spoke-sdp bound to an SDP with signaling off, but the system will use control channel status signaling rather than T-LDP status signaling. The ability to configure control channel status signaling on a specific spoke-sdp is determined by the credit based algorithm described as follows. Control-channel-status for a particular PW only counts against the credit based algorithm if it is in a no shutdown state and has a non-zero refresh timer.

Note: Shutdown of a service will cause the static PW status bits for the corresponding PW to be set.

The spoke-sdp is held down unless the pw-path-id is complete.

The system accepts the node-id of the pw-path-id saii or taii being entered as either 4-octet IP address format <a.b.c.d> or unsigned integer format.

The control-word must be enabled to use MPLS-TP on a spoke-sdp.

The pw-path-id only configurable if all of the following is true:

In the vc-switching case, if configured on a mate spoke-sdp, then the TAII of the spoke-sdp must match the SAII of its mate, and SAII of spoke-sdp has to match the TAII of its mate.

A control-channel-status no shutdown is allowed only if all of the following is true:

The hash-label option is only configurable if SDP far-end is not node-id or global-id.

The control channel status request mechanism is enabled when the request-timer <timer> parameter is non-zero. When enabled, this overrides the normal RFC-compliant refresh timer behavior. The refresh timer value in the status packet defined in RFC 6478 is always set to zero.

The refresh-timer in the sending node is taken from the request-timer. The two mechanisms are not compatible with each other. One node sends a request timer while the other is configured for refresh timer. In a specific node, the request timer can only be configured with both acknowledgment and refresh timers disabled.

When configured, the following procedures are used instead of the RFC 6478 procedures when a PW status changes.

Use the following syntax to configure control channel status requests.

3.6.3. Credit Based Algorithm

To constrain the CPU resources consumed processing control channel status messages, the system should implement a credit-based mechanism. If a user enables control channel status on a PW[n], then a certain number of credits c_n are consumed from a CPM-wide pool of max_credit credits. The number of credits consumed is inversely proportional to the configured refresh timer (the first three messages at 1 second interval do not count against the credit). If the current_credit <= 0, then control channel status signaling cannot be configured on a PW (but the PW can still be configured and no shut).

The following is an example algorithm:

If refresh timer > 0, c_n = 65535 / refresh_timer

Else c_n = 0.

For n=1, current_credit[n] = max-credits – c_n

Else current_credit [n] = current_credit [n-1] – c_n

If a PE with a non-zero refresh timer configured does not receive control channel status refresh messages for 3.5 time the specified timer value, then by default it will time out and assume a PW status of zero. A proprietary optional extension to the [RFC6478] protocol should be implemented to enable a node to resolve such a stale PW status condition by requesting the status from the far end node in certain cases.

3.7.1. Processing behavior for SAPs using VLAN ranges in access-uplink mode

The access SAPs that specifies VLAN range values using connection-profile (also known as, dot1q range SAPs) is allowed in Epipe service and in VPLS service. For more information about functionality supported, see VLAN Range SAPs feature Support and Restrictions. The system allows only one range SAP in an Epipe service. It fails any attempt to configure more than one range SAP in an Epipe service. Range SAP can be configured only on access ports. The other endpoint in the Epipe service has to be a “Q.* SAP” in access-uplink mode. The processing and forwarding behavior for packets received on range SAPs are listed as follows:

3.7.2. VLAN Range SAPs feature Support and Restrictions

3.7.3. Processing Behavior for SAPs Using VLAN Ranges in Network Operating Mode

The access SAPs that specifies VLAN range values (using connection-profile) is allowed only in an Epipe service. The system allows only one range SAP in an Epipe service. It will fail any attempt to configure more than one range SAP in an Epipe service. Range SAP can be configured only on access ports. The other endpoint in the Epipe service has to be a Q.* access SAP or a spoke-sdp (PW) in network mode. The spoke-SDP processing and forwarding behavior for packets received on range SAPs are listed as follows: No VLAN tags are removed/stripped on ingress of the access dot1q SAPs using VLAN range connection profile. When the other endpoint in the service is configured to be an Q1.* access SAP, 7210 adds another tag to the packet and forwards it out of that SAP. If the other endpoint in the service is configured to be a spoke-SDP whose vc-type is set to vc-ether, 7210 SAS adds the appropriate MPLS PW and LSP encapsulations and forwards it out of the SDP. In the reverse direction, when the other endpoint is a Q1.* SAP and a packet is received on it, 7210 SAS removes the outermost VLAN tag and forwards the packet out of the access dot1q SAP using VLAN ranges. When the other endpoint is a spoke-sdp (whose vc-type is set to vc-ether), 7210 SAS removes the MPLS PW and LSP encapsulation and forwards the packet out of the access dot1q SAP using VLAN ranges. The system does not check if the VLAN in the packet matches the VLAN IDs of the dot1q access SAPs configured in the service.

3.8.1. SDPs

The most basic SDPs must have the following:

3.8.2. SAP Encapsulations

The Epipe service is designed to carry Ethernet frame payloads, so it can provide connectivity between any two SAPs that pass Ethernet frames. The following SAP encapsulations are supported on the Epipe service:

While different encapsulation types can be used, encapsulation mismatch can occur if the encapsulation behavior is not understood by connecting devices and are unable to send and receive the expected traffic. For example if the encapsulation type on one side of the Epipe is dot1q and the other is null, tagged traffic received on the null SAP will potentially be double tagged when it is transmitted out of the Dot1q SAP.

3.8.3. QoS Policies

Traffic Management - Traffic management of Ethernet VLLs is achieved through the application of ingress QoS policies to SAPs and access egress QoS policies applied to the port. All traffic management is forwarding-class aware and the SAP ingress QoS policy identifies the forwarding class based on the rules configured to isolate and match the traffic ingressing on the SAP. Forwarding classes are determined based on the Layer 2 (Dot1p, MAC) or Layer 3 (IP, DSCP) fields of contained packets and this association of forwarding class at the ingress will determine both the queuing and the Dot1P bit setting of packets on the Ethernet VLL on the egress.

SAP ingress classification and Policing - The traffic at the SAP ingress is classified and metered according to the SLA parameters. All the traffic ingressing on the SAP is classified to a particular forwarding class. All the forwarding class is metered through and marked in-profile or put-profile based on the Meter parameters.

When applied to 7210 SAS Epipe services, service ingress QoS policies only create the unicast queues defined in the policy. The multipoint queues are not created on the service. Note that both Layer 2 or Layer 3 criteria can be used in the QoS policies for traffic classification in a service.

Egress Network DOT1P Marking - Marking of IEEE DOT1P bits in VLAN tag is as per the FC-to-Dot1p map. For details see the default network QoS policy in the 7210 SAS-M, T, Mxp, Sx, S Quality of Service Guide. This marking is applied at the port level on access ports and access uplink ports.

Ingress Network Classification - Ingress network classification is based on the Dot1p bits in the outer VLAN tag received on the access uplink port. Dot1p-to-FC mapping is based on the network ingress QoS policy.

3.8.4. Filter Policies

7210 SAS Epipe services can have a single filter policy associated on both ingress and egress. Both MAC and IP filter policies can be used on Epipe services.

3.8.5. MAC Resources

Epipe services are point-to-point layer 2 VPNs capable of carrying any Ethernet payloads. Although an Epipe is a Layer 2 service, the 7210 SAS Epipe implementation does not perform any MAC learning on the service, so Epipe services do not consume any MAC hardware resources.