4. VLL Services

4.1. In This Chapter

This chapter provides information about Virtual Leased Line (VLL) services and implementation notes.

Topics in this chapter include:

4.2. ATM VLL (Apipe) Services

This section provides information about the Apipe service. Topics in this section include:

Apipe configuration information is found under the following topics:

See Service Support for information on the adapter cards and chassis that support ATM VLL services.

4.2.1. ATM VLL for End-to-End ATM Service

ATM VLLs (Apipe) provide a point-to-point ATM service between users connected to 7705 SAR nodes or other SR routers over an IP/MPLS network (see Figure 27). User ATM traffic is connected to a 7705 SAR either directly or through an ATM access network. In both cases, an ATM PVC—for example, a virtual channel (VC) or a virtual path (VP)—is configured on the 7705 SAR. VPI/VCI translation is supported in the ATM VLL.

The ATM pseudowire (PW) is initiated using targeted LDP signaling as specified in RFC 4447, Pseudowire Setup and Maintenance using LDP; alternatively, it can be configured manually. The 7705 SAR supports MPLS, GRE, and IP as the tunneling technologies for transporting ATM PWs.

The 7705 SAR receives standard UNI/NNI cells on the ATM SAP, or on a number of SAPs belonging to a SAP aggregation group, which are then encapsulated into a pseudowire packet using N-to-1 cell mode encapsulation in accordance with RFC 4717. See ATM PWE3 N-to-1 Cell Mode Encapsulation for more information about N-to-1 cell mode encapsulation.

In addition to supporting N-to-1 cell mode encapsulation, ATM VLL service supports cell concatenation, control word (CW), SAP-to-SAP (local service), and SAP-to-SDP binding (distributed service). See SAP Encapsulations and Pseudowire Types for more information. ATM SAP-to-SAP service is not supported when N > 1; see ATM SAP-to-SAP Service for information about ATM SAP-to-SAP services.

ATM VLL optimizes the ATM cell from a 53-byte cell to a 52-byte packet by removing the header error control (HEC) byte at the near end. The far end regenerates the HEC before switching ATM traffic to the attached circuit.

Figure 27:  ATM VLL for End-to-End ATM Service 

4.2.2. ATM Virtual Trunk Over an IP/MPLS Packet-Switched Network

ATM virtual trunks (VT), also known as ATM transparent cell transport in RFC 4446, provide a transparent trunking function for user and control traffic between two ATM switches over an ATM pseudowire. ATM control traffic includes PNNI signaling and routing traffic, ILMI traffic, and F4/F5 OAM traffic. Figure 28 shows two switches labeled ATM 2 and ATM 4 that appears to be directly connected over an ATM link because the virtual trunk emulates a direct connection between the ATM switches.

Virtual trunks are supported on 7705 SAR 4-port OC3/STM1 Clear Channel Adapter cards with ports configured for OC3 or STM1 and 4-port DS3/E3 Adapter cards with ports configured for DS3 and E3.

All cells arriving on a port configured for virtual trunking on the 7705 SAR are fed to a single ATM pseudowire. The VPI range cannot be configured. No VPI/VCI translation is performed on ingress or egress. Cell order is maintained within a VT. SAP to SAP service is supported. The two ATM ports can therefore be on the same PE node.

By carrying all cells from all VPIs making up the VT in one pseudowire, a transport solution is provided that is both robust and operationally efficient since the entire VT can be managed as a single entity from the NSP NFM-P (single point for configuration, status, alarms, statistics).

ATM virtual trunks use PWE3 N:1 ATM cell mode encapsulation to provide cell-mode transport, supporting all AAL types, over the MPLS network. Cell concatenation on a pseudowire packet is supported. The SDP type can be MPLS or GRE.

The ATM pseudowire is initiated using targeted LDP (T-LDP) signaling (defined in draft-ietfpwe3-control-protocol-xx.txt, Pseudowire Setup and Maintenance using LDP). In this application, there is no ATM signaling on the 7705 SAR gateway nodes since both endpoints of the MPLS network are configured by the network operator. ATM signaling between the ATM nodes is passed transparently over the VT (along with user traffic) from one ATM port on a 7705 SAR PE to another ATM port on a remote (or the same) 7705 SAR PE.

OAM signaling behaves in the same way as user traffic in that OAM cells are transported transparently and no special action is taken when F4 or F5 OAM cells are received at the SAP ingress or egress. As well, all ILMI messages are transported transparently between two endpoints. In the case of a pseudowire failure (for example, label withdrawal, loss of reachability, loss of tunnel to the eLER), the virtual trunk service SAP port is not taken down.

Figure 28:  ATM Virtual Trunk Over IP/ MPLS Packet-Switched Network 

4.2.3. ATM SAP-to-SAP Service

ATM VLLs can be configured with both endpoints (SAPs) on the same 7705 SAR. This is referred to as an ATM SAP-to-SAP or local ATM service. An ATM SAP-to-SAP service emulates local ATM switching between two ATM endpoints on the 7705 SAR. Both ingress and egress traffic is legacy ATM traffic. The two SAPs can be any combination of supported ATM encapsulation ports, channel-groups, or IMA bundles.

Note:

ATM SAP-to-SAP connections are supported on any combination of the following:

  1. IMA group
  2. T1/E1 ASAP port
  3. E3/DS3 port
  4. OC3/STM1 port. The OC3 port can be configured for clear channel or channelized service.
Note:

ATM SAP-to-SAP connections are not supported for pseudowire packets using N-to-1 cell mode encapsulation where N > 1.

4.2.4. ATM Traffic Management Support

The 7705 SAR supports the ATM Forum Traffic Management Specification Version 4.1.

Topics in this section include:

4.2.4.1. Network Ingress Classification

Classification is based on the EXP value of the pseudowire label and EXP-to-FC mapping is determined by the network ingress QoS policy.

The ingress MPLS packets are mapped to forwarding classes based on EXP bits that are part of the headers in the MPLS packets. The EXP bits are used to ensure an end-to-end QoS application. For PW services, there are two labels: one for the MPLS tunnel and one for the pseudowire itself. Mapping is done according to the outer tunnel EXP bit settings. This ensures that if the EXP bit settings are altered along the path by the intermediate LSR nodes, the newly requested FC selection is carried out properly.

Ingress GRE and IP packets are mapped to forwarding classes based on DSCP bit settings of the IP header.

4.2.4.2. ATM Access Egress Queuing and Shaping

The 7705 SAR provides a per-SAP queuing architecture on the 16-port T1/E1 ASAP Adapter card, 32-port T1/E1 ASAP Adapter card, 4-port DS3/E3 Adapter card, and 4-port OC3/STM1 Clear Channel Adapter card. After the ATM pseudowire is terminated at the access egress point, all the ATM cells are mapped to default queue 1, and queuing is performed on a per-SAP basis.

Access ingress and access egress traffic management features are identical for SAP-to-SAP and SAP-to-SDP applications.

Note:

The ATM access egress shaping configuration in a SAP egress QoS policy is ignored when that policy is assigned to an ATM SAP. The shaping of the egress cell stream is controlled by the atm-td-profile command. If the atm-td-profile is not configured, the default atm-td-profile is in effect.

For more information on ATM access egress queuing and scheduling, refer to the 7705 SAR Quality of Service Guide.

4.2.5. Control Word

ATM VLL supports an optional control word (CW). The control word must be used for any pseudowire service that transports packets that are less than 64 bytes; see the Pseudowire Control Word and the control-word command description for more information.

4.3. Circuit Emulation VLL (Cpipe) Services

This section provides information about the Cpipe service.

Topics in this section include:

Cpipe configuration information is found under the following topics:

See Service Support for information on the adapter cards and chassis that support circuit emulation VLL services.

4.3.1. Cpipe Service Overview

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

The 7705 SAR can support TDM circuit applications that are able to transport delay-sensitive TDM traffic over a packet network. For example, in the case of cell site aggregation, Cpipe services provide transport service for 2G connectivity between the base transceiver station and the base station controller, and for 3G backhaul applications (for example, EVDO traffic from T1/E1 ports with MLPPP). Cpipe services over MPLS or GRE tunnels are supported.

The 2G 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. The 3G UMTS R99 traffic uses ATM/IMA as the transport protocol. The IMA sessions are terminated at the site by the 7705 SAR and the 3G ATM traffic is transported across the PSN through the use of ATM VLLs (PWE3).

4.3.2. TDM SAP-to-SAP Service

TDM VLLs can be configured with both endpoints (SAPs) on the same 7705 SAR. This is referred to as TDM SAP-to-SAP or local TDM service. TDM SAP-to-SAP emulates a TDM multiplexing and switching function on the 7705 SAR.

A TDM SAP-to-SAP connection is set up in the 7705 SAR and a pseudowire is configured between the two endpoints.

Note:

TDM SAP-to-SAP connections are supported between any T1/E1 port or channel that is configured for access mode and circuit emulation service and another port or channel with the same configuration (endpoint type, bit rate [number of DS0s in a channel group], payload size, CAS enabled/disabled, and RTP enabled/disabled).

4.3.3. Cpipe Service Modes

Cpipe services support unstructured circuit emulation mode (SAToP) for DS3, E3, DS1, and E1 circuits as per RFC 4553 and structured circuit emulation mode (CESoPSN) for n × 64 kb/s timeslots in DS1 and E1 circuits as per RFC 5086.

The 7705 SAR supports MEF 8, which allows both structured and unstructured emulation of TDM services across Epipes, also known as Circuit Emulation Services over Ethernet (CESoETH). See MEF 8 for more information about CESoETH.

Topics in this section include:

4.3.3.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 in order to transport the entire signal over a PSN as a pseudowire.

4.3.3.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 usage 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.

The 7705 SAR supports CESoPSN with and without CAS for DS1 and E1.

When CESoPSN with CAS is selected, the ABCD bits are coded into the T1 or E1 multiframe packets, transported within the TDM PW, and reconstructed in the T1 or E1 multiframe at the far end for each timeslot.

Channel Associated Signaling (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 multiframe allows the signaling bits for all 30 channels to be trunked.

As shown in Figure 29, timeslot 1 of all frames within the E1 multiframe is reserved for alignment, alarm indication, and CRC. For Frame 0, timeslot 17 is reserved for multiframe 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 7705 SAR.

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 multiframe and transfers all four signaling bits (ABCD). SF framing uses a 12-frame multiframe 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

When CESoPSN with CAS is selected, the ABCD bits are decoded from the incoming E1/T1 multiframe, transferred within the TDM PW, and reconstructed in the E1/T1 multiframe at the far end for every DS0 channel. CAS can be configured on a per-T1/E1 basis or on a per-DS0/64 kb/s channel basis.

Figure 29:  E1 Framing for CAS Support in an E1 Multiframe 

Table 18 shows the structure of a T1 ESF multiframe that uses RBS. The structure of a T1 SF multiframe is based on 12 frames and only the A and B bits are available.

Table 18:  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

4.3.4. TDM PW Encapsulation

TDM circuits are MPLS-encapsulated as per RFC 4553 (SAToP) and RFC 5086 (CESoPSN). (see Figure 30 and Figure 31).

For GRE tunnels, the same encapsulations shown in Figure 31 are used, but GRE tunnel headers are used instead of MPLS tunnel headers.

Figure 30:  SAToP MPLS Encapsulation 
Figure 31:  CESoPSN MPLS Encapsulation 

Figure 32 shows the format of the CESoPSN TDM payload (with and without CAS) for packets carrying trunk-specific n × 64 kb/s service.

Figure 32:  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. If only one timeslot per frame is being transported, the packet size must be an even number.

For CESoPSN with CAS, the packet size is an integer number of frames. A single T1/E1 port can have a mix of CAS and non-CAS traffic in each DS0/64 kb/s channel. You must configure the relevant T1/E1 port or channel group for CAS signal mode before provisioning the TDM PW with CAS or the system will disallow the signal mode configuration. The extra bytes for ABCD (CAS) signaling bits are not included when setting the packet size.

For a single T1/E1 port that contains a mix of CAS and non-CAS signaling, all the non-CAS channel Cpipes inherit the CAS channel restriction concerning 24/16 frames for payload size. For a T1 port, the payload size is equal to the number of CAS and/or non-CAS timeslots × 24 frames/multiframe × n multiframes, where n = 1 to 8. For an E1 port, the payload size is equal to the number of CAS and/or non-CAS timeslots × 16 frames/multiframe × n multiframes, where n =1 to 8.

Note:

The extra bytes for CAS signaling bits must be included when setting the service-mtu size. See Structured T1/E1 CES with CAS for more information.

4.3.5. Circuit Emulation Parameters and Options

Cpipe services support unstructured circuit emulation mode (SAToP) for DS3, E3, DS1, and E1 circuits as per RFC 4553, and structured circuit emulation mode (CESoPSN) for n × 64 kb/s timeslots in DS1 and E1 circuits as per RFC 5086.

Table 19 lists the adapter cards, modules, and chassis that support SAToP and CESoPSN.

Table 19:  SAToP and CESoPSN Support on the 7705 SAR 

Card/Module/Chassis

SAToP

CESoPSN

Name

CLI identifier (includes mode and channelization)

16-port T1/E1 ASAP Adapter Card

a16-chds1

  On DS0/64k

  On DS1/E1

16-port T1/E1 ASAP Adapter Card version 2

a16-chds1v2

  On DS0/64k

  On DS1/E1

32-port T1/E1 ASAP Adapter Card

a32-chds1v2

  On DS0/64k

  On DS1/E1

2-port OC3/STM1 Channelized Adapter Card

a2-choc3

  On DS0/64k

  On DS1/E1

  On DS3 1

4-port OC3/STM1 / 1-port OC12/STM4 Adapter Card

a4-choc3/12

  On DS1/E1

4-port DS3/E3 Adapter Card

a4-chds3

  On n × DS0

  On DS1 2

  On DS3/E3

12-port Serial Data Interface Card

a12-sdi

  On V.35 and X.21 ports

  On RS-232 ports

6-port E&M Adapter Card

a6-em

8-port Voice & Teleprotection Card

a8-vt

8-port FXO Adapter Card

a8-fxo

6-port FXS Adapter Card

a6-fxs

Integrated Services Card

isc

 3

4-port T1/E1 and RS-232 Combination Module

a4-combo

  On RS-232 ports

  On T1/E1 ports

7705 SAR-A

i8-chds1

7705 SAR-Hc

i2-sdi

7705 SAR-M

i16-chds1

7705 SAR-X

i8-chds1-x

    Notes:

  1. No support for E3
  2. No support for E1/64K channel groups
  3. The Integrated Services card acts as a Cpipe bridge/multicaster. There are no physical ports on the Integrated Services card.

See Service Support for further information on circuit emulation VLL services.

The following parameters and options are described in this section:

4.3.5.1. Unstructured

Unstructured CES is configured by choosing satop-t1, satop-e1, satop-t3, or satop-e3 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, E1, DS3, and E3 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 20 shows the default values for packet size and packetization delay. See Packet Payload Size for more information.

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.

Table 20:  Unstructured Payload Defaults 

Circuit

Payload Size (Octets)

Packetization Delay (ms)

DS1

192

1.00

E1

256

1.00

DS3

1024

0.183

E3

1024

0.238

4.3.5.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 21 for default and minimum payload size values. The maximum payload packet size is 1514 octets.

If a port on a 16-port T1/E1 ASAP Adapter card, version 2, or 32-port T1/E1 ASAP Adapter card is configured for DCR, the port timing is associated with the service clock of the Cpipe of channel group 1. For a framed T1 port, there is a restriction on the Cpipe payload size of channel group 1:

  1. for DCR with a timestamp frequency of 77.76 MHz, the payload size = 2 x I x (number of timeslots), where I = 1 to 20
  2. for DCR with a timestamp frequency of 19.44 MHz, the payload size = 8 x I x (number of timeslots), where I = 1 to 5

This restriction does not apply to framed E1 ports or unframed T1/E1 ports.

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. Thus, a channel group with four timeslots contributes 4 octets to the payload. The timeslots do not need to be contiguous.

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

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

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 21 shows 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 21:  Default and Minimum Payload Size for CESoPSN without CAS 

Default Values

Minimum Values

Number of Timeslots (N)

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

4.3.5.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 choosing 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 (via the signal-mode {cas} command) before configuring the Cpipe service to support DS1 or E1 with CAS. Refer to the 7705 SAR Interface Configuration Guide for information on configuring signal mode.

For n × DS0 and 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 (channel 17) cannot be included in the channel group on E1 carriers. Since the CAS in-band method is used, separate PW support for CAS is not provided.

When CAS is enabled, the packet size is based on the number of multiframes per packet and whether the circuit is configured for E1 or T1. Payload size is user-configurable to correspond to the desired integer number of multiframes. The 7705 SAR supports up to 8 multiframes, where a multiframe contains 24 frames for T1 and 16 frames for E1. Therefore, the payload size = number of timeslots × 24 (T1) or 16 (E1) frames per multiframe × number of multiframes. For example, the payload size for a T1 line (24 frames) using 2 timeslots and 8 multiframes is 384 bytes (384 = (2 × 24) × 8).

Multiple multiframes are supported on the following cards and platforms:

  1. 6-port E&M Adapter card (see note below)
  2. 16-port T1/E1 ASAP Adapter card
  3. 32-port T1/E1 ASAP Adapter card
  4. 7705 SAR-A (variant with T1/E1 ports)
  5. 7705 SAR-M (variants with T1/E1 ports)
  6. 7705 SAR-X
Note:

If the 6-port E&M Adapter card is configured for A-Law companding, the E&M ports support 16 (E1) frames per multiframe. If the card is configured for Mu-Law companding, the ports support 24 (T1) frames per multiframe.

Table 22 shows the default 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. You do not include the additional signaling bytes when setting 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 example above, since n = 4, the total payload is 64 octets plus (4/2 = 2) CAS octets, or 66 octets. Refer to Figure 32 to see 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 22:  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

4.3.5.4. Packet Payload Size

The packet payload size defines the number of octets contained in the payload of a TDM PW 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).

4.3.5.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 properly configured jitter buffer provides continuous play-out, thereby avoiding discards due to overruns and underruns (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.

Configuration/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.

For each circuit, the maximum receive jitter buffer is configurable. Play-out from this buffer must start when the buffer is 50% full, in order to give an operational PDV equal to half the maximum buffer size. The supported range is 1 to 250 ms in increments of 1 ms. The buffer size must be set to at least 3 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 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:

  1. 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 in order to ensure no loss of packets. Thus, 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).
  2. If asymmetric delay control is enabled (asym-delay-control), it must be enabled on both ends of the Cpipe and the jitter buffer size must match on both ends of the Cpipe; otherwise, a service parameter mismatch state occurs and the service is brought down.

The following values are the default jitter buffer times for structured circuits without CAS, 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

For CESoPSN with CAS, the default jitter buffer is 12 ms for T1 and 8 ms for E1.

Jitter buffer overrun and underrun 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 underruns, 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 show command.

4.3.5.6. Asymmetric Delay Control

If there is high jitter in the network, the last packet for initialization of the circuit emulation service may arrive early or late, resulting in a jitter buffer latency that is different from the expected configured jitter buffer setting (time associated with 50% jitter buffer size). The latency difference between each direction of the TDM PW is known as asymmetric latency, and because some applications (for example, power industry networks) require a very low latency difference, it must be controlled.

The asym-delay-control command is used to control the asymmetric latency contributed by the jitter buffer. When the command is enabled, a special startup sequence is triggered when the TDM PW is initially started or is restarted after being brought down (due to faults such as packet overflow, packet underflow, or the port going down).

Upon startup, a configurable number of TDM PW packets are analyzed. During this analysis period, the access port transmits an all-ones pattern (for the 8-port Voice & Teleprotection card) or the configured idle-payload-fill value (for the other port types). Refer to the 7705 SAR Interface Configuration Guide for information on the idle-payload-fill command. The service is considered to be down during this period.

If any packet loss is detected during the analysis period, the analysis is restarted. If no packet loss is detected, the average jitter buffer latency is computed. Based on the difference between the average latency and the expected latency of the jitter buffer size, the network processor will either:

  1. drop a number of octets based on the difference (if the measured average is higher than expected)
  2. add a number of dummy octets based on the difference (if the measured average is lower than expected); the dummy octets are based on the idle-payload-fill value of the channel or port
Note:

  1. Asymmetric delay control can only reduce asymmetry in the jitter buffer. It does not reduce any asymmetry that may exist in the network path.
  2. Because of this, the network must be engineered to maintain symmetrical latency:
    1. use explicit-path LSPs with strict hops
    2. do not use MPLS FRR because it may change the latency characteristics of a single direction without changing the other direction
    3. ensure that both directions of the TDM PW traverse the same path end to end
  3. With asymmetric delay control, care must be taken when designing the network to prevent a situation where an error recovery mechanism would result in different MPLS paths in the two directions of the Cpipe. If different paths are utilized, latencies may be different and asymmetry introduced. Therefore, in conjunction with asymmetric delay control, hop-by-hop strict LSPs must be used as the spoke SDP for the Cpipe with no alternative paths.

Optionally, the asymmetric delay control analysis can be set to repeat at configured time intervals after the service is up. This analysis is done with live traffic (that is, not with all-ones or the idle-payload-fill value). If the difference between the calculated average latency and the expected latency is greater than 250 μs, octets are added or dropped as necessary.

If asymmetric delay control is enabled, it must be enabled on both ends of the Cpipe; otherwise, a service parameter mismatch state occurs and the service is brought down. Jitter buffer size is also included in the set of parameters that will cause a service parameter mismatch if the value is not the same at both ends of the Cpipe. This prevents the operator from changing the jitter buffer size, which would immediately change the latency symmetry of the Cpipe service.

As well, Cpipes using asymmetric delay control must have the same card and port type on both ends of the Cpipe. Mismatched card/port configuration is not blocked in the CLI or in SNMP but must be avoided; otherwise, differential delay will be introduced caused by different framer delays on the cards/ports.

Asymmetric delay control can only be enabled for Cpipes configured as CESoPSN without CAS (no SAToP). If asymmetric delay control is enabled, ACR, DCR, and RTP cannot be enabled on the port.

The following adapter cards, modules, and platforms support asymmetric delay control:

  1. 4-port T1/E1 and RS-232 Combination module (RS-232 channels) on the 7705 SAR-H
  2. 8-port Voice & Teleprotection card (G.703 (codir) and C37.94 (TPIF) channels)
  3. 12-port Serial Data Interface card (RS-232 and X.21 channels)
  4. 7705 SAR-Hc (RS-232 channels)

4.3.5.7. 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 PW interoperability purposes only and should be enabled when the other device requires an RTP header.

RTP cannot be enabled if asymmetric delay control is enabled.

4.3.5.8. Control Word

The structure of the control word is mandatory for SAToP and CESoPSN and is shown in Figure 33. Table 23 describes the bit fields. See Pseudowire Control Word for more information.

Figure 33:  Control Word Bit Structure 
Table 23:  Control Word Bit Descriptions  

Bit

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 interworking 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. For CESoPSN, M is set according to RFC 5086, summarized as follows:

  1. When L bit = 0, and
    M = 00—Normal conditions
    M = 01—Reserved for future use
    M = 10—RDI condition for the attachment circuit (AC)
    M = 11—Reserved for CESoPSN
  2. When L bit = 1, and
    M = 00—TDM data is invalid
    M = 01—Reserved for future use
    M = 10—Reserved for future use
    M = 11—Reserved for future use

FRG

The FRG bits in the CESoPSN control word are set to 00.

LEN

The LEN bits (bits 10 to 15) carry the length of the CESoPSN packet (defined as the size of the CESoPSN header plus the payload size) if it is less than 64 bytes, and set to 0 otherwise.

Sequence number

The sequence number is used to provide the common PW sequencing function as well as detection of lost packets.

4.3.6. Transparent SDH/SONET Over Packet (TSoP)

Transparent SDH/SONET over Packet (TSoP) is a method for transporting clear channel OC3/STM1 traffic over a packet network using OC3/STM1 TSoP SFPs. With TSoP, the entire signal is encapsulated in a pseudowire and transported over the network to a single destination, which simplifies operation. TSoP is modeled after the SAToP method for pseudowire transport of DS1, E1, DS3, or E3 circuits (RFC 4553). The 7705 SAR-8 8-port Gigabit Ethernet Adapter card supports one OC3/STM1 TSoP SFP.

TSoP SFPs are inserted into Ethernet SFP ports, and the 7705 SAR treats them as standard Ethernet SFPs. To set up the TSoP service, an Epipe must be created across the network connecting two OC3/STM1 TSoP SFPs. The OC3/STM1 TSoP SFP implements DCR for service clock delivery. Both nodes must be synchronized against a common clock for DCR.

4.3.7.  Error Situations

The CE-bound interworking function (IWF) uses the sequence numbers in the control word to detect lost and incorrectly ordered packets. Incorrectly ordered packets that cannot be reordered 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. Refer to the 7705 SAR Interface Configuration Guide for 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 underruns are logged.

4.4. Ethernet VLL (Epipe) Services

This section provides information about the Epipe service.

Topics in this section include:

Epipe configuration information is found under the following topics:

See Service Support for information on the adapter cards and chassis that support Ethernet VLL services.

4.4.1. Epipe Service Overview

An Ethernet pseudowire (PW) is used to carry Ethernet/802.3 protocol data units (PDUs) over an MPLS or IP network, allowing service providers to offer emulated Ethernet services over existing MPLS or IP networks. For the 7705 SAR, Ethernet emulation is a point-to-point service.

The 7705 SAR uses Ethernet VLLs to carry Ethernet traffic from various sources at a site, including traffic such as e911 locators, power supply probes, and HSPA-dedicated interfaces. Native Ethernet bridging is not supported.

An MPLS Epipe service is the Nokia implementation of an Ethernet VLL based on the IETF RFC 4448, Encapsulation Methods for Transport of Ethernet over MPLS Networks.

Figure 34 shows a typical Ethernet VLL frame together with its MPLS tunnel encapsulation.

Figure 34:  Ethernet VLL Frame with MPLS Encapsulation 

An Epipe service is a Layer 2 point-to-point service where the customer data is encapsulated and transported across a service provider’s MPLS or IP network. Figure 35 shows a typical Epipe Service. An Epipe service is completely transparent to the subscriber’s data and protocols. Like other PW VLL services, Epipe service behaves like a non-learning Ethernet bridge. A distributed Epipe service consists of a SAP and an SDP pair, where one SDP is on same router as the SAP, and the second SDP is on the far-end router.

Each SAP configuration includes a specific port on which service traffic enters the 7705 SAR from the customer side (also called the access side). Each port is configured with an encapsulation type (SAP encapsulation). Thus, a whole Ethernet port can be bound to a single service (that is, the whole Ethernet port is configured as a SAP), or if a port is configured for IEEE 802.1Q or 802.1ad encapsulation (referred to as dot1q or qinq, respectively), then a unique encapsulation value (ID) must be specified.

Figure 35:  Epipe Service 

4.4.2. Ethernet Access Egress Queuing and Scheduling

Ethernet access egress queuing and scheduling is very similar to the Ethernet access ingress behavior. Once the Ethernet pseudowire is terminated, traffic is mapped to up to eight different forwarding classes per SAP. Mapping traffic to different forwarding classes is performed based on the EXP bit settings of the received Ethernet pseudowire.

For more information on Ethernet access egress queuing and scheduling, refer to the 7705 SAR Quality of Service Guide.

4.4.3. Ethernet SAP-to-SAP

Ethernet VLLs can be configured with both endpoints (SAPs) on the same 7705 SAR. This is referred to as Ethernet SAP-to-SAP or local Ethernet service. Ethernet SAP-to-SAP provides local Ethernet switching between two Ethernet endpoints on the 7705 SAR.

An Ethernet SAP-to-SAP connection is set up on the 7705 SAR and a pseudowire is configured between the two endpoints.

When the port encapsulation is null, there is no change to the VLAN tags on the ingress and egress frame headers, if VLAN tags are present.

When the port encapsulation is dot1q, the VLAN tag is removed from the ingress frame header and a new VLAN tag is inserted into the egress frame header. No VLAN tag is inserted into the egress frame header if the SAP has a VLAN ID of 0.

When the port encapsulation is qinq, the VLAN tags are removed from the ingress frame header and a new set of outer and inner VLAN tags are inserted in the egress frame header. No VLAN tags are inserted in the egress frame if the SAP has a VLAN ID of 0 or VLAN IDs of 0.*. SAP 0.0 is not a valid combination.

4.4.4. MEF 8

The 7705 SAR supports MEF 8 as defined in the Implementation Agreement for the Emulation of PDH Circuits over Metro Ethernet Networks. Support for the MEF 8 standard allows both structured and unstructured emulation of TDM services across Epipes, also known as Circuit Emulation Services over Ethernet (CESoETH). The MEF 8 feature enables the 7705 SAR to interoperate with equipment that does not support MPLS-based Cpipes but does support MEF 8 Epipes.

Figure 36 shows an Ethernet-encapsulated TDM circuit. See TDM PW Encapsulation for complete information about TDM PW encapsulation.

Figure 36:  CESoETH Encapsulation 

The 7705 SAR supports the following MEF 8 configuration scenarios:

  1. TDM SAP to Ethernet SAP (see Figure 37)
    A GPON ONT or other MEF 8-only device is used to encapsulate TDM over a GPON or Ethernet network, and the 7705 SAR is used to terminate the MEF 8.
  2. TDM SAP to Ethernet SAP via 7705 SAR-M GPON module (see Figure 38)
    The 7705 SAR-M is the GPON ONT and is used to interoperate with a MEF 8-only device. The 7705 SAR-M terminates the MEF 8.
  3. TDM SAP to spoke SDP (see Figure 39)
    A GPON ONT or other MEF 8-only device is used to encapsulate TDM over an MPLS network, and the 7705 SAR is used to terminate both the LSP and MEF 8.
Figure 37:  TDM SAP to Ethernet SAP 
Figure 38:  TDM SAP to Ethernet SAP via 7705 SAR-M GPON Module 
Figure 39:  TDM SAP to Spoke SDP 

Table 24 shows the platforms, adapter cards, and modules that support MEF 8.

Table 24:  MEF 8 Support on the 7705 SAR 

TDM SAP to Ethernet SAP

TDM SAP to Ethernet via Epipe Spoke SDP

Structured 1

Unstructured

Structured 1

Unstructured

7705 SAR-M

All T1/E1 ports

 2

 2

7705 SAR-A

All T1/E1 ports

 2

 2

7705 SAR-X

All T1/E1 ports

 2

 2

16-port T1/E1 ASAP Adapter card

 2

 2

32-port T1/E1 ASAP Adapter card

 2

 2

2-port OC3/STM1 Channelized Adapter card

 3

 3

4-port DS3/E3 Adapter card

 4

 4

4-port OC3/STM1 / 1-port OC12/STM4 Adapter card

 5

 5

4-port T1/E1 and RS-232 Combination module

All T1/E1 ports

 2

 2

    Notes:

  1. Supported on n x DS0 channels with or without CAS
  2. Supported on DS1/E1 ports
  3. Supported on DS1/E1 channels and DS3/E3 channels
  4. Supported on DS1/E1 channels and DS3/E3 ports
  5. Supported on DS1/E1 channels

4.4.4.1. Epipe Service Modes

Epipe services support structured circuit emulation mode for nxDS0 and structured or unstructured circuit emulation mode for DS1, E1, DS3, and E3 as defined in the MEF 8 specification.

There are two methods for using MEF 8 to emulate TDM circuits over Ethernet using an Epipe:

  1. TDM SAP-to-Ethernet SAP
  2. TDM SAP-to-spoke SDP

Defining one TDM SAP and one Ethernet SAP is known as Circuit Emulation Services over Ethernet (CESoETH). The TDM SAP configured in the Epipe must include a local and remote Emulated Circuit Identifier (ECID) and a far-end destination MAC address. The TDM port’s MAC address is used as the source MAC address for the circuit.

TDM can also be encapsulated into Ethernet which is then encapsulated in MPLS (or GRE). This method is known as Circuit Emulation Services over Ethernet over MPLS (CESoETHoMPLS). CESoETHoMPLS is configured with an Epipe with a TDM SAP and a spoke SDP. The TDM SAP configured in the Epipe must include a local and remote ECID and a far-end destination MAC address. The TDM port’s MAC address is used as the source MAC address for the circuit.

The 7705 SAR supports unicast MAC addresses and non-IEEE-reserved group multicast MAC addresses.

Note:

Users should exercise caution when using multicast MAC addresses, as Ethernet frames with a multicast destination address could be flooded when traversing an Ethernet broadcast domain.

The TDM SAP’s framing and CAS settings determine the MEF 8 circuit emulation mode. If the TDM port is framed, MEF 8 is in structured mode. If the TDM port is unframed, MEF 8 is in unstructured mode. If the TDM SAP is configured with CAS enabled, MEF 8 is in structured mode with CAS. See Unstructured, Structured DS1/E1 CES without CAS, and Structured T1/E1 CES with CAS for more information about circuit emulation modes.

Adaptive clock recovery (ACR) is supported for MEF 8 in structured or unstructured mode on the following platforms and adapter cards:

  1. 7705 SAR-F (T1/E1 ports)
  2. 7705 SAR-M (variants with T1/E1 ports)
  3. 7705 SAR-A (variants with T1/E1 ports)
  4. 7705 SAR-X (T1/E1 ports)
  5. 16-port T1/E1 ASAP Adapter card
  6. 32-port T1/E1 ASAP Adapter card

For more information on ACR, refer to the 7705 SAR Basic System Configuration Guide, “Adaptive Clock Recovery (ACR)”.

Differential clock recovery (DCR) is supported for MEF 8 in structured or unstructured mode on the following platforms, adapter cards, and modules:

  1. 7705 SAR-M (variants with T1/E1 ports)
  2. 7705 SAR-A (variant with T1/E1 ports)
  3. 7705 SAR-X (T1/E1 ports)
  4. 16-port T1/E1 ASAP Adapter card, version 2
  5. 32-port T1/E1 ASAP Adapter card
  6. 4-port OC3/STM1 / 1-port OC12/STM4 Adapter card (DS1/E1 channels)
  7. 4-port DS3/E3 Adapter card (clear channel DS3/E3 ports and DS1/E1 channels on channelized DS3 ports (E3 ports cannot be channelized)); DCR on DS1/E1 channels is supported only on the first three ports of the card
  8. T1/E1 ports of the 4-port T1/E1 and RS-232 Combination module

To enable DCR, the network must have a common clock between the two terminating SAPs or SAP/spoke SDP using MEF 8. In each direction, the service clock is compared to the common clock and the difference is encoded into the RTP header in the TDM PW overhead. At the other end of the network, the original service clock is reproduced by comparing the common clock to the frequency difference in the RTP header.

Note:

DCR is not supported on DS1 or E1 channels that have CAS signaling enabled.

For more information on DCR, refer to the 7705 SAR Basic System Configuration Guide, “Differential Clock Recovery (DCR)”.

4.4.5. Ethernet OAM

Ethernet VLL service supports Ethernet OAM functions for ETH-CFM according to the 802.1ag and Y.1731 standards, for Y.1731 Performance Monitoring, and for EFM OAM according to the 802.3ah standard. For more information, see ETH-CFM (802.1ag and Y.1731), and refer to the “Ethernet OAM” section in the 7705 SAR Interface Configuration Guide, and the “Ethernet OAM Capabilities” section in the 7705 SAR OAM and Diagnostics Guide.

Ethernet ports in access or network mode also support CFM loopback message (LBM) frames for Layer 1 and Layer 2 OAM tests on unlabeled ports. For more information, refer to the “Ethernet OAM” section in the 7705 SAR Interface Configuration Guide.

4.4.6. Control Word

Ethernet VLL supports an optional control word (CW). The control word contains protocol control information and must be used for any pseudowire service that transports packets that are less than 64 bytes; see Pseudowire Control Word for more information.

4.4.7. MTU

Network-facing Ethernet ports must support a larger MTU than access-facing Ethernet ports in order to account for the pseudowire headers that are added to the access Ethernet frames.

As an example, the following list gives the worst-case MTU sizes for Ethernet VLLs over Ethernet ports under various configurations, where the worst case is the largest MTU size required in order to carry a standard payload (1500 bytes):

  1. Access, null mode: 1514 bytes
  2. Access, dot1q mode: 1518 bytes
  3. Access, qinq mode: 1522 bytes
  4. Network, null mode: 1572 bytes
  5. Network, dot1q mode: 1572 bytes
Note:

Since it is not practical to split a Layer 2 Ethernet frame into smaller frames, the access port (SAP) MTU must be smaller than the service and network port MTU. If the access port MTU is larger than the tunnel MTU, the Ethernet VLL does not come into service and remains in the inoperative state. See MTU Settings for information on MTU for VLL service.

4.4.8. Raw and Tagged Modes

An Ethernet PW operates in one of two modes: raw or tagged. Raw and tagged modes relate to the way the router handles VLAN tags embedded in the header of an Ethernet frame. Both modes are supported by the 7705 SAR.

Raw and tagged modes are configured using the vc-type {ether | vlan} parameter under the spoke-sdp command. To configure raw mode, choose the ether option; to configure tagged mode, choose vlan.

VLAN tags can provide service-delimiting information about a frame. Service-delimiting means that information in the tag affects the forwarding decisions that are made to route the packet. The port connected to the attachment circuit (AC) can be configured for null, dot1q, or qinq operation. When the port is configured for null, the 7705 SAR treats any attached tag received at the SAP (from the AC) as not service-delimiting; when configured for dot1q or qinq, received tags are service-delimiting.

4.4.8.1. Raw Mode

In raw mode, VLAN tags are not service-delimiting (that is, the port is set to null and the tags do not affect frame forwarding decisions) and are forwarded over the Epipe as part of the payload.

If a service-delimiting tag arrives from the ingress AC (that is, the port is set to dot1q or qinq and a tag is received), the tags are removed (popped) from the payload before the Ethernet frame gets switched over the PSN via the Epipe.

In raw mode, all traffic from the ingress port gets switched to the same endpoint. However, if the MTU (or configured size) of the tunnel is exceeded then service is affected because the frame is dropped.

In raw mode, when the 7705 SAR detects a failure on the Ethernet ingress port or the port is administratively disabled, the 7705 SAR sends a PW status notification message to the remote router.

4.4.8.2. Tagged Mode

In tagged mode, every frame sent on the Ethernet PW has a service-delimiting VLAN tag. If the frame received by the 7705 SAR from the attachment circuit (AC) does not have a service-delimiting VLAN tag, then the 7705 SAR inserts (pushes) a VLAN tag into the frame header before sending the frame to the SDP and the PW. If the frame received from the AC has a service-delimiting VLAN tag, the tag is replaced.

In tagged mode, when the 7705 SAR detects a failure on the Ethernet physical port or the port is administratively disabled, the 7705 SAR sends a PW status notification message for all PWs associated with the port.

4.4.8.3. VLAN Translation

VLAN ID translation is supported, as appropriate. Table 27 (see Tagging Rules for Epipe) shows the VLAN ID translation operation for the various packet types. The payload part of the packet is shown in parentheses.

The operations to add, strip (remove), or forward the VLAN headers are performed based on the encapsulation type at the ingress of the attachment circuit (the SAP), in the network, and at the egress circuit.

4.4.8.4. Tagging Rules for Epipe

Table 25 and Table 26 show the general tagging rules for combinations of interface port type (null, dot1q, or qinq) and Epipe type (Ethernet or VLAN) for SAP ingress and SAP egress directions.

An AC (attachment circuit, ingress or egress) can be configured for one of the following encapsulation types:

  1. null
  2. dot1q
  3. qinq
Note:

  1. Single-tagged Ethernet packets with VLAN ID set to 0 are handled in the same way as other tagged packets.
  2. For Ethernet VLL SAP-to-SAP with a VLAN SAP, the dot1p header is not popped at ingress. Instead, it is preserved across the ingress and egress ports to ensure dot1p transparency. Dot1q bits are overwritten with configured VLAN information at egress. If there is a matching non-default QoS policy applied at egress, the dot1p bits are re-marked accordingly.
Table 25:  Ingress SAP Tagging Rules 

Ingress SAP Type  1

VC Type (Epipe)

Raw (Ethernet)

Tagged (VLAN)

Null

No operation

Push (VC tag)

Dot1q

Pop (outer tag)

Pop (outer tag)

Push (VC tag)  2

QinQ

Pop (outer tag)

Pop (outer tag)

Push (VC tag)

    Notes:

  1. Ingress SAP type is configured at the port level.
  2. If the VC tag is not set, then the original tag is preserved. The VC tag is set on the spoke SDP, using the vlan-vc-tag command.
Table 26:  Egress SAP Tagging Rules 

Egress SAP Type  1

VC Type (Epipe)

Raw (Ethernet)

Tagged (VLAN)

Null

No operation

Pop (VC tag)

Dot1q

Push (SAP tag)  2

Pop (VC tag)

Push (SAP tag)  3

QinQ

Push (SAP tags)

Pop (VC tag)

Push (SAP tags)

    Notes:

  1. Egress SAP type is configured at the port level.
  2. If the SAP tag is 0, then no VLAN tag is pushed.
  3. If the SAP tag is 0, then only the pop operation is performed.

Table 27 shows several examples of how VLAN tags are translated as they flow from ingress to egress. The ingress or egress point can be a SAP or an SDP. For a SAP, encapsulation can be null, dot1q, or qinq; for an SDP, encapsulation (vc-type) can be ether raw or VLAN (tagged). When the SAP encapsulation is dot1q or qinq, outer and inner tags are used.

Note:

When the SAP type is dot1q or qinq:

  1. the SAP VLAN tag always delimits the ingress traffic, regardless of the Ethernet VLL type (raw or tagged)
  2. untagged frames are dropped at the SAP ingress. That is, only the frames with an outer VLAN tag that matches the SAP VLAN tag are forwarded. The exception to this case occurs when the VLAN tag = 0. When a SAP is configured with VLAN ID = 0, any received untagged packets are processed.
Table 27:  VLAN Tagging Examples (Epipe)  

Example

Configuration Settings

Rx (Ing)/

Tx (Egr)

SAP/

SDP

Encap.

SAP VLAN Tag

Outer

Inner

1

Rx

Tx

SAP

SAP

Null

Null

N/A

N/A

N/A

N/A

Result: Untagged, single-, and double-tagged frames are accepted. On egress, all frames are transmitted untouched.

2

Rx

Tx

SAP

SAP

Dot1q

Null

252

N/A

N/A

N/A

Result: Single- and double-tagged frames are accepted if the outermost VLAN ID matches. On egress, the outermost VLAN tag is popped.

3

Rx

Tx

SAP

SAP

QinQ

Dot1Q

525

789

353

N/A

Result: Double-tagged frames are accepted if the outer/inner VLAN ID matches. On egress, the outer VLAN tag is popped and the inner VLAN tag is swapped.

4

Rx

Tx

SAP

SDP

QinQ

VLAN

525

456

353

N/A

Result: Double-tagged frames are accepted if the outer/inner VLAN ID matches. On egress, the outer VLAN tag is popped and the inner VLAN tag is swapped.

5

Rx

Tx

SDP

SAP

Ether

QinQ

N/A

123

N/A

654

Result: Untagged, single-, and double-tagged frames are accepted. On egress, a double-push (outer and inner) is performed.

6

Rx

Tx

SAP

SDP

Dot1q

VLAN

Default (*)

741

N/A

N/A

Result: Untagged, single-, and double-tagged frames are accepted. On egress, a push is performed.

7

Rx

Tx

SAP

SDP

QinQ

VLAN

852

963

0

N/A

Result: Single- and double-tagged frames are accepted if the outermost VLAN ID matches. On egress, the outermost VLAN tag is swapped.

8

Rx

Tx

SAP

SAP

QinQ

QinQ

Default (*)

Default (*)

Default (*)

Default (*)

Result: Any double-tagged frames are accepted. On egress, all frames are transmitted untouched.

4.4.9. IP Filters (Epipe)

IP filters are applied to Epipe SAPs in the ingress direction, as described below. For a full list of entities to which IP filters can be applied, see IP Filter Policies.

Ethernet pseudowires are generally used to transparently switch traffic across an MPLS network to the far end. However, in some cases, the traffic that is switched over the network, consuming valuable bandwidth, is just discarded at the other end of the pseudowire. As well, with the 7705 SAR expanding into areas such as vertical markets, and with local area networks being connected to the 7705 SAR Ethernet ports, an increasing amount of traffic must stay local and not pass through the MPLS network to the far end. By using IP filters at the access ingress, operators can determine what traffic is passed through the pseudowire and therefore use the network links more efficiently.

IP filters can also be used for security purposes, by allowing access only to designated services (for example, allowing e-mail and FTP services while disallowing Telnet services) at the origin of the traffic.

IP filter policies specify either a forward or a drop action for packets, based on information specified in the match criteria. Within each filter policy, you can create entries that define matching criteria.

The same IP filter policy can be assigned to any entity (network interfaces, IP pseudowires, Ethernet pseudowires, IES, and VPRN services), all of which can be configured on the same adapter card. For example, a filter policy defined as “filter-5” can be assigned to multiple Epipe SAPs and, simultaneously, to network interfaces on the same adapter card.

A filter policy assigned to an entity on one adapter card can also be assigned to any entity on another adapter card. For example, a filter policy defined as “filter-2” can be assigned to an Epipe on an Ethernet Adapter card and to a network interface on another Ethernet Adapter card.

Assigning the same filter policy to different entities on a card counts as using one filter policy.

Configuration and assignment of filter policies is similar for network interfaces, IES management SAPs, Ethernet and IP pseudowire SAPs, VPRN and IES SAPs and spoke SDPs, and VPLS SAPs and SDPs (spoke and mesh). This guide describes the assignment of filter policies to SAPs and SDPs. Refer to the 7705 SAR Router Configuration Guide, “Filter Policies”, for information on configuring filter policies and assigning them to network interfaces.

4.4.10. MPLS Entropy Label

For Epipes, the router supports MPLS entropy labels as per RFC 6790. The entropy label provides greater granularity for load balancing on an LSR where load balancing is typically based on the MPLS label stack.

For more information, refer to the “MPLS Entropy Labels” section in the 7705 SAR MPLS Guide and to the “LAG and ECMP Hashing” section in the 7705 SAR Interface Configuration Guide.

4.5. Frame Relay VLL (Fpipe) Services

This section provides information about the Fpipe service. Topics in this section include:

Fpipe configuration information is treated under the following topics:

See Service Support for information on the adapter cards and chassis that support frame relay VLL services.

4.5.1. Fpipe Service Overview

The frame relay VLL (Fpipe) provides a point-to-point frame relay service between users connected to 7705 SAR nodes or other SR routers over an IP/MPLS network. Users are connected to the 7705 SAR nodes using frame relay PVCs.The 7705 SAR receives a standard Q.922 core frame on the frame relay SAP and encapsulates it into a pseudowire packet according to the 1-to-1 frame relay encapsulation mode in RFC 4619 Encapsulation Methods for Transport of Frame Relay over Multiprotocol Label Switching (MPLS) Networks.

The MPLS tunnel label is used by MPLS LSRs to forward a PW packet from one PE to the other. The PW label identifies one PW (that is, one LSP) assigned to an FR VC in one direction. Together the MPLS tunnel label and PW label form an MPLS label stack, as described in RFC 3032.

The control word contains protocol control information and must be used for any pseudowire service that transports packets that are less than 64 bytes; see FR PW Control Word for more information. The payload field corresponds to X.36/X.76 FR frame information field with the following components removed: bit/byte stuffing, FR header, and FCS.The maximum length of the payload field must be agreed on by the two PEs; this agreement can be achieved by using the MTU interface parameter when the PW is established (RFC 4447).

Figure 40 shows an example of the frame relay VLL end-to-end service.

Figure 40:  FR VLL for End-to-End FR Service 

Fpipe SAPs are supported on the following:

  1. 16-port T1/E1 ASAP Adapter card, version 2
  2. 32-port T1/E1 ASAP Adapter card
  3. 4-port DS3/E3 Adapter card
  4. 12-port Serial Data Interface card
  5. T1/E1 ports on the 7705 SAR-M (variants with T1/E1 ports)

Before an Fpipe can be configured on an MDA that supports multiple MDA modes, namely the 16-port T1/E1 ASAP Adapter card, version 2, the 32-port T1/E1 ASAP Adapter card, and the 4-port DS3/E3 Adapter card, the mda-mode command must be set to cem-fr-hdlc-ppp. Likewise, the AC port that is bound to the Fpipe SAP must have the encap-type command set to frame-relay. Refer to the 7705 SAR Interface Configuration Guide for more information about how to set the mda-mode command at the card level and the encap-type command at the port/channel level. See Service Support for more information about the supported chassis and the port- and channel-level configuration requirements.

4.5.2. FR SAP-to-SAP Service

FR VLLs can be configured with both endpoints (SAPs) on the same 7705 SAR, which is referred to as an FR SAP-to-SAP or local FR service. FR SAP-to-SAP emulates local FR switching between two FR endpoints on the same 7705 SAR node.

4.5.3. FR Traffic Management

Traffic management of frame relay VLLs is achieved through the application of ingress and egress QoS policies to SAPs.

4.5.3.1. Ingress SAP Classification and Marking

If the de-1-out-profile is configured, DE=1 frames are classified as out-of-profile and are not subject to the CIR marking. All received DE=0 frames that exceed the CIR are marked as out-of-profile and have the DE set to 1 regardless of whether the de-1-out-profile command is enabled or disabled. Refer to the 7705 SAR Quality of Service Guide for more information about the de-1-out-profile command.

4.5.4. FR Encapsulation

Figure 41 shows the standard FR frame.

Figure 41:  FR Frame 

Figure 42 shows the one-to-one mapping mode for FR encapsulation over an MPLS network according to RFC 4619. The FR service payload can be n octets.

Figure 42:  FR PW 1-to-1 MPLS PSN Encapsulation 

The native FR PDU is processed as follows:

  1. Flag—The FR flags are removed during encapsulation.
  2. FCS—The FCS can use a 2-byte CRC-CCITT or a 4-byte CRC-32. The CRC is configurable. The FCS is removed during encapsulation.
  3. Frame header—A 2-byte DLCI frame header is supported. The header is removed during encapsulation.
  4. The F, B, D, and C control bits are copied into the control word as described in FR PW Control Word.

4.5.4.1. FR PW Control Word

The control word is required for FR one-to-one mode. Figure 43 shows the FR PW control word.

Figure 43:  FR PW Control Word 

Table 28 describes the bits used in the FR PW control word.

Table 28:  Control Word Bit Descriptions  

Bit

Description

Bits 0 to 3

4 bits. Bits 0 to 3 are always set to 0 to indicate the presence of the PW.

F

Bit 4; FR FECN bit. The F bit is copied from the FR frame.

B

Bit 5; FR BECN bit. The B bit is copied from the FR frame.

D

Bit 6; FR DE bit. The D bit is copied from the FR frame, but can be reset as a result of the ingress frame policy, as described in FR Traffic Management.

C

Bit 7; FR frame C/R bit. The C bit is copied unchanged from the FR frame.

FRG

2 bits (bits 8 and 9).

FRG bits are not supported. The bits must be set to 0.

Length

6 bits (bits 10 to 15). If the frame length (defined as the length of the FR Layer 2 payload plus the length of the control word) is less than 64 octets, the length field must be set to the PW payload length. Otherwise, the length field must be set to zero. The value of the length field, if non-zero, is used to remove the padding characters by the egress PE. See the control-word command description for more information.

Sequence Number

A 16-bit, unsigned circular space. Sequence numbers provide a mechanism to ensure the ordered delivery of PW packets.

The sequence number field is not supported. The sequence number value 0 indicates that the sequence number check algorithm is not used.

4.5.5. Status Signaling and OAM Propagation

The 7705 SAR supports the mapping and notification of defect states between an FR PW and an ACs in accordance with Pseudowire (PW) OAM Message Mapping draft-ietf-pwe3-oam-msg-map-14.txt, Section 10. Failures in the network are propagated to the customer edge using LMI messages. LMI and AC failures are propagated to the network using PW status signaling.

4.6. HDLC VLL (Hpipe) Services

This section provides information about the Hpipe service. Topics in this section include:

Hpipe configuration information is found under the following topics:

See Service Support for information on the adapter cards and chassis that support HDLC VLL services.

4.6.1. Hpipe Service Overview

An HDLC PW is used to carry HDLC PDUs over an MPLS network. HDLC PWs enable service providers to offer emulated HDLC services over existing MPLS networks.

HDLC mode provides port-to-port transport of HDLC-encapsulated traffic.The HDLC PDU is transported in its entirety, including the HDLC address and control fields, but the HDLC flags and the FCS are excluded. If the optional control word is used, the flag bits in the control word are not used and must be set to 0 for transmitting and must be ignored upon receipt.

HDLC PWs are implemented in accordance with RFC 4618.

Hpipe SAPs are supported on the following:

  1. 16-port T1/E1 ASAP Adapter card, version 2
  2. 32-port T1/E1 ASAP Adapter card
  3. 12-port Serial Data Interface card
  4. T1/E1 ports on the 7705 SAR-M (variants with T1/E1 ports)

Before HDLC SAPs can be configured on the 16-port T1/E1 ASAP Adapter card, version 2, and the 32-port T1/E1 ASAP Adapter card, the mda-mode command must be set to cem-fr-hdlc-ppp at the card level. Refer to the 7705 SAR Interface Configuration Guide for more information about how to set the mda-mode command. See Service Support for more information about the supported chassis and the port- and channel-level configuration requirements.

Only ports that are configured with HDLC encapsulation can be mapped to an Hpipe SAP. HDLC encapsulating ports do not terminate the HDLC. The ports pass the HDLC frames through the Hpipe. HDLC encapsulated ports can pass through any HDLC-framed traffic, such as Cisco-HDLC, FR, PPP, and so on.

HDLC encapsulation can be used on a port to transmit Cisco-HDLC frames over an H-pipe. To transport Cisco-HDLC traffic over an Hpipe, the attachment circuit (AC) port that is bound to the Hpipe SAP must have the encap-type command set to hdlc, not cisco-hdlc. Refer to the 7705 SAR Interface Configuration Guide for more information about how to set the encap-type command.

Note:

A Cisco-HDLC encapsulating port cannot be bound to an Hpipe SAP. A Cisco-HDLC encapsulating port can only be bound to an Ipipe SAP. See IP Interworking VLL (Ipipe) Services for more information.

4.6.2. HDLC VLL for End-to-End HDLC Service

Figure 44 shows an example of how a mobile operator can deploy end-to-end HDLC services over an MPLS network.

Figure 44:  HDLC VLL for End-to-End HDLC Service 

In Figure 44, the CE (an ATM switch) transmits HDLC PDUs and receives HDLC PDUs over the physical layer between the CE and a 7705 SAR (PE1). The native service processing (NSP) function in PE1 performs the packet processing, such as bit stuffing, PW-PW bridging, L2 encapsulation, shaping, and policing, for the HDLC packets that are forwarded to the PW termination point in PE1. The PW, which terminates at a logical port in the PE1, delivers the unaltered HDLC packets that are received across the MPLS network to the corresponding logical port on PE2 at the other end of the PW.

The PW termination points on each PE represent the operations that establish and maintain the PW and that encapsulate and decapsulate the HDLC packets. For more information, refer to the PW reference diagram packet processing that supports the HDLC PW as described in RFC 4618.

4.6.3. HDLC SAP-to-SAP Service

HDLC VLLs can be configured with both endpoints (SAPs) on the same 7705 SAR, which is referred to as an HDLC SAP-to-SAP or local HDLC service. HDLC SAP-to-SAP emulates local HDLC switching between two endpoints on the same 7705 SAR node.

4.6.4. HDLC Encapsulation

Figure 45 shows a typical HDLC VLL frame.

Figure 45:  HDLC VLL Frame 

Figure 46 shows a typical HDLC VLL frame together with its MPLS tunnel encapsulation.

Figure 46:  HDLC VLL Frame with MPLS Encapsulation 

The native HDLC PDU is processed as follows:

  1. Flag—the HDLC flags are removed during encapsulation
  2. FCS—the FCS can use a 2-byte CRC-CCITT or a 4-byte CRC-32. The CRC is configurable. The default value is 2-byte. The FCS is removed during encapsulation.
  3. Address—HDLC address is retained
  4. Control—HDLC control is retained

The MPLS tunnel is used to transport the encapsulated HDLC across the PSN and the PW header is appended to the modified HDLC PDU as described in RFC 4618. The HDLC control word is inserted in the frame before the HDLC payload. See HDLC PW Control Word and Payload Size for information.

4.6.4.1. HDLC PW Control Word and Payload Size

To switch frames through the 7705 SAR switch fabric, the frame size must be 64 bytes or larger. If the HDLC frames received at the SAP are not 64 bytes or larger, the 7705 SAR pads the HDLC payload at the access ingress to ensure that the HDLC payload can be passed through the switch fabric and transported properly across the network. When padding occurs, the size of the original payload must be indicated in the length field of the control word so that at the termination of HDLC PW, the far-end device can correctly determine the actual size of the HDLC payload, remove the padding, and forward the original, non-padded HDLC payload to the access egress. See RFC 4618, section 4.1 part-2. Figure 47 shows the HDLC PW control word.

Figure 47:  HDLC PW Control Word 

Table 29 describes the bits used in the HDLC PW control word.

Table 29:  Control Word Bit Descriptions  

Bit

Description

Bits 0 to 3

The use of bits 0 to 3 is described in RFC 4385. The bits are always set to 0 to indicate the presence of the CW.

Flags

4 bits (bits 4 to 7). No flags are defined for the HDLC PW. The bits must be set to 0, and must be ignored by the PE.

FRG

2 bits (bits 8 and 9). FRG bits are not supported. The bits must be set to 0.

Length

6 bits (bits 10 to 15). The length represents the combined size of the CW and the HDLC payload. If the combined size is less than 64 bytes, this field must be populated to indicate the actual size of the HDLC payload that is received at the access ingress. At the access egress, this field is used to strip bytes that are appended for padding purposes. If the combined size of the CW and the HDLC payload exceeds 64 bytes, all bits in this field must be set to 0. See the control-word command description for more information.

Sequence Number

The sequence number is used to provide the common PW sequencing function as well as detection of lost packets. The sequence number field is not supported on the 7705 SAR.

See Pseudowire Control Word for more information.

4.6.5. Status Signaling

The HDLC PW supports status signaling in accordance with RFC 4618, section 5.1. When the PE detects a status change in the attachment circuit (AC) status, such as an AC physical link failure, or if the AC is administratively disabled, the PE sends the appropriate PW status notification message that corresponds to the HDLC AC status. The local PW status is also reflected in a PW status notification message, as described in RFC 4447, section 5.4.

4.6.5.1. OAM Propagation

The 7705 SAR supports OAM propagation between AC SAPs and the PW and vice-versa. For example, if no viable tunnel exists from the AC to the eLER, the status of the local SAP is set to the down state. Likewise, when a local SAP fails, the 7705 SAR sends a PW status message informing the far end of an AC ingress/egress fault. The far-end eLER then sets the status of the service and the SAP to the down state.

4.7. IP Interworking VLL (Ipipe) Services

This section provides information about the Ipipe service.

Topics in this section include:

Ipipe configuration information is found under the following topics:

See Service Support for information on the adapter cards and chassis that support IP interworking VLL services.

4.7.1. Ipipe Service Overview

An Ipipe pseudowire (IP PW) enables service interworking between different link layer technologies and network interworking between connections with the same link layer technologies. IP PWs provide an efficient means to connect Layer 3 IP traffic to the IP/MPLS network, even without access to VLANs.

An Ipipe is a point-to-point Layer 2 service where the customer data is encapsulated and transported across an MPLS or IP network. An Ipipe service transparently forwards all packets received on one SAP to the other SAP. No native IP routing of customer packets occurs.

IP interworking allows connections to be created with any combination of PPP, MLPPP, Ethernet, LAG, FR, and Cisco HDLC (cHDLC) SAPs, but the payload must always be IP. Ipipes can be used to transport IP payloads more efficiently than Epipes because an Ipipe service does not need to forward the Ethernet header information.

Figure 48 shows an example of IP connectivity between a host attached to a point-to-point access circuit (FR, cHDLC, and PPP) with routed PDU IPv4 encapsulation and a host attached to an Ethernet interface. Both hosts are on the same LAN segment.

Figure 48:  IP Pseudowires Between SAR Nodes 

A frame relay SAP makes use of RFC 2427, Multiprotocol Interconnect over Frame Relay, routed PDU encapsulation of an IPv4 packet. A PPP interface makes use of RFC 1332, The PPP Internet Protocol Control Protocol (IPCP), for PPP IPCP encapsulation of an IPv4 packet. A Cisco HDLC SAP uses the routed IPv4 encapsulation. The PW uses the IP Layer 2 transport pseudowire encapsulation type.

4.7.2. IP Interworking VLL Datapath

In order to be able to forward IP packets between CE 1 and CE 3 in Figure 48, PE 2 is configured with both CE 1 and CE 3 IP addresses. These are host addresses and are entered in the /32 format.

Note:

Addresses can be configured manually or by using CE Address discovery.

PE 2 maintains an ARP cache context for each IP interworking VLL and responds to ARP request messages received on the Ethernet SAP. PE 2 responds with the Ethernet SAP configured MAC address as a proxy for any ARP request for the CE 1 IP address. PE 2 silently discards any ARP request messages received on the Ethernet SAP for addresses other than CE 1. Likewise, PE 2 silently discards any ARP request messages with source IP addresses other than CE 3. In all cases, PE 2 keeps track of the association of IP to MAC addresses for ARP requests it receives over the Ethernet SAP. All entries are subject to aging.

In order to forward unicast frames destined for CE 3, PE 2 needs to know the MAC address of CE 3. If there is no entry in the ARP cache, PE 2 sends an ARP request message for the CE 3 MAC address over the Ethernet SAP.

IP broadcast and IP multicast packets are sent on the Ethernet SAP using the broadcast or direct-mapped multicast MAC address.

In order to forward unicast frames destined for CE 1, PE 2 validates the MAC destination address of the received Ethernet frame. It should match that of the Ethernet SAP. PE 2 then removes the Ethernet header and encapsulates the IP packet directly into a pseudowire with or without the optional control word. PE 1 removes the pseudowire encapsulation and forwards the IP packet over the SAP using PPP encapsulation.

When a packet reaches the access egress and the configured SAP is over a VLAN, the node pushes (inserts) the appropriate VLAN tag into the Ethernet frame header before forwarding the Ethernet frame out of the port. Ethernet frames at the access egress can also be marked with appropriate dot1 priority bits if the dot1 priority QoS profile is assigned to the forwarding class configuration.

Ethernet frames mapped to an Ipipe service can have a maximum of two VLAN tags. Frames with more than two VLAN tags are dropped at the Ipipe access ingress SAP.

At access ingress, PE 1 performs proxy PPP negotiation and provides the IP address of the remote CE 3 device to CE 1 during IPCP negotiation using the IP-Address option.

A PE does not flush the ARP cache unless the SAP goes administratively or operationally down. The PE with the Ethernet SAP sends unsolicited ARP requests to refresh the ARP cache according to the refresh interval. ARP requests are staggered at an increasing rate if no reply is received to the first unsolicited ARP request. The refresh interval is configurable using the mac-refresh CLI command.

4.7.3. CE IP Address Discovery and Distribution

The following subsections describe the customer edge (CE) IP address discovery methods and how the CE IP address is distributed to remote PE nodes. Topics include:

4.7.3.1. Manual IP Configuration

Manually configured IP addresses are supported for all attachment circuit types. No further mechanisms for detecting the local or remote CE IP address are required. The PE responds to all ARP requests arriving on Ethernet attachment circuits by replying with the local interface MAC address and the remote CE IP address.

4.7.3.2. CE IP Address Discovery Using ARP

Ethernet attachment circuits can be configured to use ARP messages that are received from the CE device to determine the local CE IP address. The PE waits for an ARP request from the CE in order to learn the IP address that is associated with the MAC address of the CE. When a valid ARP request is received by the PE from the CE, the ARP cache on the PE is populated with the CE IP/MAC entry. The PE accepts any ARP request message that it receives over the Ethernet SAP and updates the ARP cache entries with no further check. The PE does not validate the source IP address of the ARP request message nor does it try to match the IP address in the ARP request with the programmed IP address.

The 7705 SAR always replies to an ARP request message that is received over the Ethernet SAP. The 7705 SAR replies with the SAP MAC address and a source IP address of the IP address being ARPed without any further check of the latter.

If the SAP status changes to operationally down or if an operator manually clears the ARP cache, the system flushes the ARP cache and the CE address discovered on the SAP is cleared. When the SAP comes into service initially or after a failure, an unsolicited ARP request is not sent over the Ethernet SAP. In the case where multiple ARP messages are received from different CE devices, the last received message prevails and the ARP cache is populated with the newly received information.

An SNMP trap is generated whenever an ARP entry or IPv4 CE address entry is discovered or changed for an Ipipe service.

Prior to Release 7.0, Ipipe IPv4 ARP packets were transmitted by bypassing the service SAPs. These packets are now sent using the service SAP. This enables normal service SAP functions such as QoS, statistics, and filtering to apply to these packets.

4.7.3.3. CE IP Address Discovery for Frame Relay

Frame relay access circuits use INVARP to learn a local CE address and to propagate the remote CE address.

4.7.3.4. CE IP Address Discovery for cHDLC

The cHDLC access circuits do not need to discover the IP address of the local and remote CE for point-to-point interfaces. The IP addresses remain 0.0.0.0.

4.7.3.5. CE IP Address Discovery for PPP/MLPPP

The address of a locally attached CE device can be learned via IPCP. If the Ipipe uses a spoke SDP, when the 7705 SAR sends the label mapping message, this learned address is not included in the address list TLV in the interface parameters field of the pseudowire FEC TLV.

4.7.3.6. CE IP Address Distribution to Remote PE Nodes

The PE includes an IP address list TLV in the label mapping message of the PW FEC in order to communicate the local CE IP address to the remote PE. If the IP address is set to 0.0.0.0, it is assumed that the connected CE IP address is unknown. For point-to-point connections such as frame relay and cHDLC, an IP address of 0.0.0.0 does not affect the PW status or stop the flow of IP traffic through the Ipipe. Broadcast interfaces such as Ethernet must learn the local CE IP address and MAC relationship before unicast traffic can be sent, but the remote PE IP address can remain as 0.0.0.0. The value of the remote PE IP address is always 0.0.0.0 when the remote PE access circuit is PPP/MLPPP (IPCP) or cHDLC.

If the CE IP address changes, an LDP notification message is sent to the remote PE with the new IP address of the CE.

4.7.4. IP SAP-to-SAP Service

IP VLLs can be configured with both endpoints (SAPs) on the same 7705 SAR, which is referred to as an IP SAP-to-SAP or local IP service. IP SAP-to-SAP emulates local IP switching between two endpoints on the same 7705 SAR node.

4.7.5. Hardware Support for Interworking IP PWs

Table 30 lists the hardware that supports interworking IP PWs.

Table 30:  Hardware Support for Interworking PWs  

MDA Type

Interworking PWs

Eth to IP PW

PPP to IP PW

MLPPP to IP PW

MC-MLPPP to IP PW

FR to IP PW

cHDLC to IP PW

ATM to IP PW

8-port Ethernet Adapter card

6-port Ethernet 10Gbps Adapter card

8-port Gigabit Ethernet Adapter card

10-port 1GigE/1-port 10GigE X-Adapter card

— x1-10gb-sf+ mode

— x10-1gb-sfp mode

16-port T1/E1 ASAP Adapter card, version 1

— Channelized

— Clear channel

16-port T1/E1 ASAP Adapter card, version 2

— Channelized

— Clear channel

32-port T1/E1 ASAP Adapter card

— Channelized

— Clear channel

4-port DS3/E3 Adapter card

— on n x DS0

— on DS1/E1

— Clear channel (DS3 or E3)

2-port OC3/STM1 Channelized Adapter card

— on n x DS0

— on VT1.5/VC12

12-port Serial Data Interface card

— on RS-232 ports

— on V.35/X.21 ports

4-port SAR-H Fast Ethernet module

4-port T1/E1 and RS-232 Combination module

6-port SAR-M Ethernet module

7705 SAR-A

7705 SAR-Ax

7705 SAR-H

7705 SAR-M

7705 SAR-W

7705 SAR-Wx

7705 SAR-X

4.7.6. Control Word

IP interworking VLL supports an optional control word. The control word contains protocol control information and must be used for any pseudowire service that transports packets that are less than 64 bytes; see Pseudowire Control Word for more information.

4.7.7. Termination at Access

The following sections describe the termination requirements and features for interworking pseudowires. Topics include:

4.7.7.1. PPP and MLPPP Termination

For PPP termination, ports must be configured in access mode with IPCP encapsulation. Access ports on the 12-port Serial Data Interface card or 2-port OC3/STM1 Channelized Adapter card must be configured with IPCP encapsulation to support PPP/MLPPP termination for an interworking pseudowire. The ppp-auto encapsulation type applies only to network-side terminations.

4.7.7.2. FR Termination

The following features are supported for FR termination:

  1. ports must be configured for access mode according to Q.922 Annex A frame format
  2. RFC 2427, Multiprotocol Interconnect over Frame Relay, routed PDU encapsulation of an IPv4 packet
  3. UNI DCE and DTE
  4. NLPID (0xCC) IPv4 encapsulation
  5. LMI. See FR LMI.
  6. configurable service MTU of 1 to 2048 bytes. When encapsulated in the IPv4 PDU, the FR flags, FCS, and FR header are removed. The resulting data is the Ipipe payload represented in the IP Datagram field in Figure 49.
    Figure 49:  FR Header with NLPID Support for IP Interworking PW 

4.7.7.3. cHDLC Termination

The following features are supported for cHDLC termination:

  1. ports must be configured for access mode according to the cHDLC frame format. Refer to the 7705 SAR Interface Configuration Guide for information about how to configure the encap-type command to cisco-hdlc.
  2. IP encapsulation (0x0800). Figure 50 shows the cHDLC header frame.
  3. keepalive support using SLARP (0x8035). Figure 51 shows the SLARP keepalive frame.
  4. configurable service MTU of 1 to 2048 bytes. When encapsulated in the IPv4 PDU, the cHDLC packet shown in Figure 50 is modified to remove the flag, address, control, protocol ID, and FCS.
Figure 50:  cHDLC Header Frame 
Note:

cHDLC encapsulation cannot be used to transmit HDLC frames into an Ipipe.

Figure 51:  SLARP Keepalive Frame 

Refer to the 7705 SAR Interface Configuration Guide for more information about how to configure access ports for interworking IP PWs.

4.7.7.4. PPP and MLPPP Termination on 2-port OC3/STM1 Channelized Adapter Cards

One use for PPP and MLPPP termination to IP pseudowires is in fixed backhaul networks with customers connected to the network via DS1/E1 or n x DS1/E1 rates.

Figure 52 shows an example of a network using PPP and MLPPP encapsulation to IP PWs on a 2-port OC3/STM1 Channelized Adapter card.

Figure 52:  PPP and MLPPP to IP PWs on 2-port OC3/STM1 Channelized Adapter Cards 

Customer traffic aggregation remains on the available SONET/SDH infrastructure and is sent to a 2-port OC3/STM1 Channelized Adapter card on the 7705 SAR, where the PPP/MLPPP encapsulation termination takes place. Using an IP PW with PPP/MLPPP encapsulation from a SAP-to-VLAN SAP, the 7705 SAR passes the data to a 7750 SR. The 7750 SR offers the necessary scale of IP services, such as IES or VPRN, needed to handle the large amount of traffic coming from each OC3/STM1 port.

After terminating PPP/MLPPP encapsulated traffic on a channelized OC3/STM1 port, the 7705 SAR switches the IP traffic, without performing any IP lookup, to another SAP over an Ipipe. IP traffic is then passed on to the 7750 SR with a unique VLAN identifier on a per-connection basis.

Refer to the 7705 SAR Interface Configuration Guide for more information about how to configure 2-port OC3/STM1 Channelized Adapter card ports for interworking IP PWs and PPP/MLPPP termination.

4.7.8. Traffic Management

4.7.8.1. Traffic Management for FR IW SAPs

Traffic management of interworking SAPs is achieved by applying ingress and egress QOS policies to SAPs. Access ingress forwarding classes are determined by inspecting the DSCP marking of the IP packets to determine the queuing and the EXP bit setting of packets. If all traffic for a DLCI must be classified as a single forwarding class, you can define a policy to classify all DSCP values from the IP header to one forwarding class.

4.7.9. Status Signaling

4.7.9.1. FR LMI

LMI enables the exchange of information between the CE and the LER about the status of the link, device, and logical circuit. The frame relay CE device (the DTE) begins an LMI exchange by sending a Status Enquiry message. DTE status enquiry message supports link integrity verification requests. The frame relay network (the DCE) completes the exchange by responding with a Status message.

The DCE status messages support the following response types:

  1. full status
  2. link integrity verification
  3. single PVC status

The LMI protocol operates over a dedicated PVC of a frame relay link. Since LMI occupies its own PVC, its link signaling cannot congest or interfere with traffic on the PVCs that carry subscriber data.

The following standards are supported:

  1. ANSI T.617 Annex D
  2. ITU-T Q.922 Annex A
  3. Cisco Rev.1

4.7.10. IP Filters (Ipipe)

IP filters are applied to Ipipe SAPs in the ingress direction, as described below. For a full list of entities to which IP filters can be applied, see IP Filter Policies.

IP pseudowires are generally used to transparently switch traffic across an MPLS network to the far end. However, in some cases, the traffic that is switched over the network, consuming valuable bandwidth, is just discarded at the other end of the pseudowire. As well, with the 7705 SAR expanding into areas such as vertical markets, and with local area networks being connected to the 7705 SAR Ethernet ports, an increasing amount of traffic must stay local and not pass through the MPLS network to the far end. By using IP filters at the access ingress, operators can determine what traffic is passed through the pseudowire and therefore use the network links more efficiently.

Another use for IP filters is in cases where a customer router is connected to an access port on the 7705 SAR with PPP/MLPPP encapsulation. The service provider may want to filter incoming traffic from the customer at the boundaries of the network.

IP filters can also be used for security purposes, by allowing access only to designated services (for example, allowing e-mail and FTP services while disallowing Telnet services) at the origin of the traffic.

IP filter policies specify either a forward or a drop action for packets, based on information specified in the match criteria. Within each filter policy, you can create entries that define matching criteria.

The same IP filter policy can be assigned to any entity (network interfaces, IP pseudowires, Ethernet pseudowires, IES, and VPRN services), all of which can be configured on the same adapter card. For example, a filter policy defined as “filter-5” can be assigned to multiple Ipipe SAPs and, simultaneously, to network interfaces on the same adapter card.

A filter policy assigned to an entity on one adapter card can also be assigned to any entity on another adapter card. For example, a filter policy defined as “filter-2” can be assigned to an Ipipe on an Ethernet Adapter card and to a network interface on another Ethernet Adapter card.

Assigning the same filter policy to different entities on a card counts as using one filter policy.

Configuration and assignment of filter policies is similar for network interfaces, IES management SAPs, Ethernet and IP pseudowire SAPs, VPRN and IES SAPs and spoke SDPs, and VPLS SAPs and SDPs (spoke and mesh). This guide describes the assignment of filter policies to SAPs and SDPs. Refer to the 7705 SAR Router Configuration Guide, “Filter Policies”, for information on configuring filter policies and assigning them to network interfaces.

4.8. Pseudowire Switching

Topics in this section include:

4.8.1. Overview

The pseudowire switching feature provides the user with the ability to create a VLL service by cross-connecting two spoke SDPs.

Services with one SAP and one spoke SDP are created normally on the PE; however, when a pseudowire originates at customer equipment and not the 7705 SAR, the target destination of the SDP is the 7705 SAR pseudowire switching node instead of the remote PE. In such cases, the user must configure a VLL service on the pseudowire switching node (the 7705 SAR, in this case) using the two SDPs and no SAP. This creates a VLL service that travels over two different types of tunnels. The first pseudowire segment connects the Node B to the 7705 SAR, and the second segment connects the 7705 SAR to a 7750 SR node. Figure 53 shows an example of a VLL pseudowire switching service.

For the 7750 SR node, there is no implementation change required. The pseudowire segment is treated as a 7705 SAR-initiated dynamic ATM pseudowire. The 7705 SAR signals for the ATM pseudowire and negotiates all required parameters, including the pseudowire label, control word, and VCCV type.

The pseudowire switching node acts in a passive role with respect to signaling of the pseudowires. The node waits until one or both of the PEs send the label mapping message before relaying it to the other PE. This is because it needs to pass the interface parameters of each PE to the other. For example, the 7705 SAR assumes the pseudowire payload from the Node B, then signals for the ATM pseudowire to the far end and negotiates all required parameters, including the pseudowire label, control word, and VCCV type.

The switching pseudowire inserts a pseudowire switching point TLV indicating the system address in the label mapping message. This TLV is useful because it allows for troubleshooting of the path of the pseudowire, especially if multiple pseudowire switching points exist between the two PEs. The TLV also helps in loop detection of T-LDP signaling messages, where a switching point receives a label mapping message that it already relayed. The switching point TLV is inserted in pseudowire status notification messages when they are sent end-to-end or from a pseudowire switching node towards a destination PE. See Pseudowire Switching TLV for more information.

Pseudowire OAM is supported for dynamic switching pseudowires and allows the 7705 SAR pseudowire switching node to relay end-to-end pseudowire status notification messages between the two PEs. The 7705 SAR can generate a pseudowire status and send it to one, or both, of the PEs by including its system address in the pseudowire switching point TLV. This allows a 7705 SAR PE to identify the origin of the pseudowire status notification message.

The pseudowire segment between the 7705 SAR and the 7750 SR supports OAM tools as well as BFD; however, since Node Bs are not dual-homed, OAM tools operating on this pseudowire segment can only provide informative messages. The 7705 SAR responds to Node B-initiated ping packets if the destination IP address is the system IP or interface IP address of the 7705 SAR. If the IP packet does not contain a SAR destination IP address, the 7705 SAR does not respond, and instead, forwards the packet.

Figure 53 shows an example of static-simplex to dynamic-simplex pseudowire switching. This service consists of a SAP and a spoke SDP. However, the target destination of the SDP is not the remote PE but the pseudowire switching node. In addition, the user configures a VLL service on the pseudowire switching node using the two SDPs.

Figure 53:  Simplex to Simplex Pseudowire Switching 

Configuration examples can be found in Configuring PW Switching.

Table 31 shows the pseudowire switching options supported on the 7705 SAR.

Table 31:  Supported Pseudowire Switching Options  

PW Segment 1

PW Segment 2

Tunnel

PW

Tunnel

PW

E-

pipe

F-

pipe

H-

pipe

I-

pipe

A-

pipe

Cpipe-ces

Cpipe

-satop

RSVP-TE, LDP, Static MPLS, IP, or GRE/IP

Static

RSVP-TE, LDP, Static MPLS, IP, or GRE/IP

T-LDP (with or without pseudowire redundancy)

RSVP-TE, LDP, Static MPLS, IP, or GRE/IP

T-LDP

RSVP-TE, LDP, Static MPLS, IP, or GRE/IP

T-LDP

IP

Static  1

MPLS-Static

Static  1

    Note:

  1. A static- to-static pseudowire switching service will fail if there is more than one S-PE node between the T-PE nodes.

The 7705 SAR supports use of an optional control word on both pseudowire segments. Use of a control word is negotiated by the 7705 SAR and 7750 SR during the signaling phase. The 7705 SAR and 7750 SR negotiate during the signaling phase even if a control word is not used. If a control word is used, the 7705 SAR generates it and configures it with all 0s.

When the 7705 SAR appends or strips the control word to support VCCV ping type 1, the TTL value of the switched pseudowire is reset to 255. If the control word is present on the ingress pseudowire packet and it is not removed because it is on an end-to-end service, the 7705 SAR reduces the pseudowire TTL by 1 at the time of pseudowire switching.

4.8.2. Pseudowire Switching with Pseudowire Redundancy

Pseudowire switching with pseudowire redundancy supports one redundant pseudowire with up to four redundant spoke SDPs. Figure 54 shows an example of a network with simplex to redundant pseudowire switching.

Figure 54:  Simplex to Redundant Pseudowire Switching 

To enable pseudowire redundancy, the first pseudowire segment must be a static pseudowire (that is, T-LDP disabled). The second pseudowire segment can then be configured with up to four redundant spoke SDPs. See Pseudowire Redundancy for instructions on configuring redundancy. Pseudowire switching with pseudowire redundancy also supports standby signaling. See Active/Standby Mode for Pseudowire Redundancy (Standby Signaling) for more information.

4.8.3. Pseudowire Switching Behavior

In the network in Figure 55, T-PE nodes act as masters and pseudowire switching nodes (S-PE nodes) act as slaves for the purpose of pseudowire signaling. Switching nodes need to pass the SAP interface parameters of each PE to the other PE. T-PE1 sends a label mapping message for the Layer 2 FEC to the peer pseudowire switching node; for example, S-PE1. It includes 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 a similar operation and forwards a label mapping message to T-PE2.

Figure 55:  Pseudowire Switching Network 

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 affect the spoke SDP cross-connect only when both directions of the pseudowire have been signaled and matched.

Pseudowire status notification messages can be generated by the T-PE nodes and/or the S-PE nodes. Pseudowire status notification 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. If the S-PE node is not the originator or if there is no TLV with the system address in the message, this means that the message was originated by a T-PE node. In this case, the S-PE processes and passes the message without changes except for the VC ID value in the FEC TLV.

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

  1. When the local status for both spokes is up, the S-PE passes any received SAP or SDP-binding generated status notification message unchanged. For example, the status notification TLV is unchanged but the VC-ID in the FEC TLV is set to the value of the pseudowire segment to the next hop.
  2. When the local operational status for any of the spokes is down, the S-PE always sends SDP-binding down status bits regardless if the received status bits from the remote node indicated SAP up or down or SDP-binding up or down.

When one segment of the pseudowire cross-connect at the S-PE is static while the other is signaled using T-LDP, the S-PE operates much like a T-PE from a signaling perspective and as an S-PE from a data plane perspective. The S-PE signals a label mapping message as soon as the local configuration is complete. The control word C-bit field in the pseudowire FEC is set to the value configured on the static spoke SDP.

When the label mapping for the egress direction is also received from the T-LDP peer, and the information in the FEC matches that of the local configuration, the static-to-dynamic cross-connect is established.

In a static-to-dynamic pseudowire switching service, it is possible for the end nodes of the static pseudowire segment to be misconfigured. In this case, an S-PE or T-PE node may receive packets with the wrong encapsulation. If this happens, an invalid payload might be forwarded over the pseudowire or the SAP respectively.

Furthermore, if the S-PE or T-PE node is expecting the control word in the packet encapsulation, and the received packet arrives with no control word but the first nibble below the label stack is 0x0001, the packet may be mistaken for a VCCV OAM packet and may be forwarded to the CSM. In that case, the CSM will perform a check of the IP header fields. If any of the fields fail the check, the VCCV packet will be discarded.

4.8.3.1. Pseudowire Switching With IP Tunnels

You cannot enable T-LDP dynamic pseudowire establishment on pseudowire switching segments using IP tunnels if the second pseudowire segment is configured for pseudowire redundancy. The pseudowire label, control word, VCCV type, and so on, must be configured manually.

On the first pseudowire segment, ATM pseudowires are natively transported over IP using GRE encapsulation with the IP type set to 0x8847, or IP encapsulation. The destination IP address of pseudowire packets received from the Node B must be set to the system IP or interface IP address of the 7705 SAR. Similarly, the destination IP address of pseudowire packets received from the 7750 SR must be set to the system IP or interface IP address of the Node B. Node B management traffic is transported over the same Ethernet link between the 7705 SAR and the Node B. The 7705 SAR forwards the management IP traffic to its destination based on longest prefix match.

On the second pseudowire segment, ATM pseudowires are transported over MPLS tunnels. The MPLS tunnels can also be used to transport additional cell site traffic, such as BTS traffic using TDM pseudowires, or LTE base station traffic using IP or Ethernet pseudowires.

4.8.4. Pseudowire Switching TLV

Figure 56 shows the format of the pseudowire switching TLV and Table 32 describes the fields.

Figure 56:  Pseudowire Switching TLV 
Table 32:  Pseudowire Switching TLV Field Descriptions  

Field

Description

PW sw TLV Length

Specifies the total length of all the following pseudowire switching point TLV fields in octets

Type

Encodes how the Value field is to be interpreted

Length

Specifies the length of the Value field in octets

Value

Octet string of Length octets that encodes information to be interpreted as specified by the Type field

The following list describes details specific to pseudowire switching point sub-TLVs:

  1. pseudowire ID of last pseudowire segment traversed
  2. pseudowire switching point description string—an optional description string of text up to 80 characters long
  3. IP address of pseudowire switching point—an optional sub-TLV containing the IPv4 address of the pseudowire switching point
  4. MH VCCV capability indication

4.9. VLL Service Considerations

This section describes the general 7705 SAR service features and any special capabilities or considerations as they relate to VLL services.

Topics in this section include:

4.9.1. Service Support

The section describes hardware support for the following VLL services:

  1. ATM
  2. Ethernet
  3. Frame relay
  4. TDM
  5. HDLC
  6. IP interworking
ATM

ATM VLL service is supported on the following:

  1. T1/E1 ports on the 2-port OC3/STM1 Channelized Adapter card (when the port is configured for ATM or IMA)
  2. T1/E1 ports on the 4-port DS3/E3 Adapter card (when the port is configured for ATM or IMA)
  3. 4-port OC3/STM1 Clear Channel Adapter card (when the port is configured for ATM)
  4. 16-port T1/E1 ASAP Adapter card (when the port is configured for ATM or IMA)
  5. 32-port T1/E1 ASAP Adapter card (when the port is configured for ATM or IMA)
  6. T1/E1 ports on the 7705 SAR-M (variants with T1/E1 ports)
Ethernet

Ethernet VLL service is supported on the following:

  1. 6-port Ethernet 10Gbps Adapter card
  2. 8-port Ethernet Adapter card
  3. 8-port Gigabit Ethernet Adapter card
  4. 10-port 1GigE/1-port 10GigE X-Adapter card
  5. Ethernet ports on the 7705 SAR-A (both variants)
  6. Ethernet ports on the 7705 SAR-Ax
  7. Ethernet ports on the 7705 SAR-H
  8. Ethernet ports on the 7705 SAR-Hc
  9. Ethernet ports on the 7705 SAR-M (all variants)
  10. 7705 SAR-W
  11. Ethernet ports on the 7705 SAR-Wx (all variants)
  12. Ethernet ports on the 7705 SAR-X
  13. 6-port DSL Combination module
  14. 8-port xDSL module
  15. GPON module
  16. 4-port SAR-H Fast Ethernet module
  17. 6-port SAR-M Ethernet module
Frame Relay

Frame relay VLL service is supported on the following:

  1. DS3/E3 clear channel or channelized DS1/E1 ports on the 4-port DS3/E3 Adapter card
  2. V.35 and X.21 serial ports on the 12-port Serial Data Interface card
  3. 16-port T1/E1 ASAP Adapter card, version 2
  4. 32-port T1/E1 ASAP Adapter card
  5. T1/E1 ports on the 7705 SAR-M (variants with T1/E1 ports)
TDM

TDM VLL service is supported on the following:

  1. T1/E1 ports and DS3 channels on the 2-port OC3/STM1 Channelized Adapter card
  2. T1/E1 ports (DS3 ports only) and DS3/E3 ports on the 4-port DS3/E3 Adapter card
  3. T1/E1 ports on the 4-port OC3/STM1 / 1-port OC12/STM4 Adapter card
  4. 6-port E&M Adapter card (when the port is configured for cem encapsulation)
  5. 8-port Voice & Teleprotection card
  6. 12-port Serial Data Interface card
  7. 16-port T1/E1 ASAP Adapter card
  8. 32-port T1/E1 ASAP Adapter card
  9. 4-port T1/E1 and RS-232 Combination module
  10. T1/E1 ports on the 7705 SAR-A (variant with T1/E1 ports)
  11. RS-232 serial ports on the 7705 SAR-Hc
  12. T1/E1 ports on the 7705 SAR-M (variants with T1/E1 ports)
  13. T1/E1 ports on the 7705 SAR-X
HDLC

HDLC VLL service is supported on the following:

  1. V.35 and X.21 serial ports (super-rate speeds only) on the 12-port Serial Data Interface card
  2. 16-port T1/E1 ASAP Adapter card, version 2
  3. 32-port T1/E1 ASAP Adapter card
  4. T1/E1 ports on the 7705 SAR-M (variants with T1/E1 ports)
IP Interworking

IP interworking VLL service is supported on the following:

  1. 2-port OC3/STM1 Channelized Adapter card (when the payload is configured as vt1.5/vc12)
  2. DS3/E3 clear channel ports on the 4-port DS3/E3 Adapter card (when the port is configured for frame-relay encapsulation)
  3. 6-port Ethernet 10Gbps Adapter card
  4. 8-port Ethernet Adapter card
  5. 8-port Gigabit Ethernet Adapter card
  6. 10-port 1GigE/1-port 10GigE X-Adapter card
  7. V.35 and X.21 serial ports (super-rate speeds only) on the 12-port Serial Data Interface card (when the port is configured for ipcp, frame-relay, or cisco-hdlc encapsulation)
  8. 16-port T1/E1 ASAP Adapter card (on PPP/MLPPP connections)
  9. 32-port T1/E1 ASAP Adapter card (on PPP/MLPPP connections)
  10. all ports on the 7705 SAR-A (on PPP/MLPPP connections on the T1/E1 ports)
  11. 7705 SAR-H
  12. Ethernet ports on the 7705 SAR-Ax
  13. Ethernet ports on the 7705 SAR-Hc
  14. all ports on the 7705 SAR-M (on PPP/MLPPP connections on the T1/E1 ports; variants with T1/E1 ports also support frame relay and HDLC SAPs on the T1/E1 ports)
  15. 7705 SAR-W
  16. Ethernet ports on the 7705 SAR-Wx (all variants)
  17. 7705 SAR-X
  18. 4-port SAR-H Fast Ethernet module
  19. 6-port SAR-M Ethernet module
Note:

MPLS and VLL service over MPLS are not supported on access ports.

4.9.2. SDPs

The most basic SDPs must have the following characteristics:

  1. a locally unique SDP identification (ID) number and a VC-ID
  2. the system IP address of the far-end 7705 SAR routers
  3. an SDP encapsulation type—GRE, IP, or MPLS

4.9.2.1. SDP Statistics for VLL Services

The 7705 SAR supports local CLI-based and SNMP-based statistics collection for each VC used in the SDPs. This allows for traffic management of tunnel usage by the different services and, with aggregation, the total tunnel usage.

4.9.3. SAP Encapsulations and Pseudowire Types

The section describes encapsulations and PW types for the following VLL services:

  1. Apipe
  2. Cpipe
  3. Epipe
  4. Fpipe
  5. Hpipe
  6. Ipipe
Apipe

ATM VLLs can be configured with both endpoints (SAPs) on the same router or with the two endpoints on different routers. In the latter case, Pseudowire Emulation Edge-to-Edge (PWE3) signaling can be used to establish a pseudowire between the devices, allowing ATM traffic to be tunneled through an MPLS or IP network.

Note:

ATM SAP-to-SAP connections are not supported for pseudowire packets using N-to-1 cell mode encapsulation where N > 1.

As an alternative to signaled pseudowires, manual configuration of pseudowires is also supported.

The Apipe service supports virtual trunking, VP connections, and VC connections, which are identified by specifying the vc-type when provisioning the Apipe. When vc-type is atm-cell, ATM transparent cell transport mode is used for VT connections. The N-to-1 cell transport mode is supported for VC and VP services (see ATM PWE3 N-to-1 Cell Mode Encapsulation). For VCCs, the value of N can be 1 (N = 1) or greater than 1 (N > 1). The value of N is always 1 for VPCs.

The supported PW service types are 0x0009 (for ATM N-to-1 VCC cell mode, where N is ≥ 1), 0x000A (for ATM N-to-1 VPC cell mode, where N = 1) and 0x0003 (for ATM transparent cell transport mode). Refer to RFC 4717 and RFC 4446 for more information.

Cpipe

Cpipe service supports CESoPSN and SAToP encapsulation over MPLS or GRE tunnels to connect to the far-end circuit. Cpipes support SAP-to-SAP and SAP-to-spoke SDP binding with a default service MTU of 1514 bytes.

The supported PW service types are 0x0011 (SAToP E1), 0x0012 (SAToP T1), 0x0013 (SAToP E3), 0x0014 (SAToP T3), 0x0015 (CESoPSN basic mode), and 0x0017 (CESoPSN TDM with CAS).

Epipe

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

  1. Ethernet null
  2. Ethernet dot1q
  3. Ethernet qinq

While different encapsulation types can be used at either end, encapsulation mismatching can occur if the encapsulation behavior is not understood by connecting devices and if those devices 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 be double-tagged when it is transmitted out of the dot1q SAP.

The supported PW service types are 0x0004 (Ethernet tagged mode), and 0x0005 (Ethernet raw).

Fpipe

Fpipe service supports frame relay services over an MPLS PSN. MPLS label switched paths—also referred to as MPLS tunnels—are used to forward PW packets between two PEs.

The 7705 SAR supports one-to-one mapping of FR VCs to PWs. An MPLS tunnel can contain several PWs, but each PW encapsulates the traffic of one FR VC.

Fpipes support SAP-to-SAP and SAP-to-spoke SDP binding.

Fpipe service supports the 0x0019 (frame relay DLCI) PW service type.

Hpipe

The 7705 SAR supports many-to-one mapping of HDLC PDUs to PWs, which is also known as port mode encapsulation.The Hpipe provides port-to-port transport of HDLC-encapsulated traffic. The HDLC PDU is transported from PE port to PE port in its entirety, including the HDLC address and control fields, but excluding HDLC flags and the FCS.

Hpipes support SAP-to-SAP and SAP-to-spoke SDP binding.

Hpipe service supports the 0x0006 (HDLC) PW service type.

Ipipe

Ipipe service supports Ethernet null, Ethernet dot1q, Ethernet qinq, IPCP, PPP/MLPPP, FR, and cHDLC SAP encapsulation over IP or MPLS. Ipipes support SAP-to-SAP and SAP-to-spoke SDP binding with a default service MTU of 1500 bytes.

Ipipe service supports 0x000B (IP Layer 2 Transport) PW service type.

4.9.4. ATM PWE3 N-to-1 Cell Mode Encapsulation

The 7705 SAR supports N-to-1 cell mode encapsulation for ATM VPCs and VCCs (per RFC 4717), where N represents the number of VCs or VPs that can be multiplexed onto a single ATM VLL.

For VCCs, N is a configurable value where N can be greater than or equal to 1 (N ≥ 1). VCC cell mode supports the 0x0009 (ATM N-to-1 VCC Cell Mode) PW service type. The N > 1 cell mode encapsulation enables service providers to multiplex multiple ATM VCs onto a single VLL to optimize the use of PWs in the network, to reduce the associated overhead of maintaining the PWs, and to increase the bandwidth available to transport user data. N > 1 cell mode encapsulation is implemented on the 7705 SAR using SAP aggregation groups. See SAP Aggregation Groups for more information about how to configure a SAP aggregation group.

For VPCs, N is not user-configurable and must be equal to 1 (N = 1). VPC cell mode supports the 0x000A (ATM N-to-1 VPC Cell Mode) PW service type.

In N-to-1 mode, OAM cells are transported through the VLL in the same way as any other cell.

An optional control word (CW) is supported for ATM VLLs. See Pseudowire Control Word for more information.

Figure 57 shows the structure of an N-to-1 cell mode frame.

Figure 57:  N-to-1 Cell Mode Encapsulation 

4.9.4.1. N-to-1 Cell Mode Encapsulation (N = 1)

The following sections describe ATM cell mode encapsulation where N = 1.

4.9.4.1.1. Deployment Scenario for N = 1 Cell Mode Encapsulation

In a typical network multiple cell sites are aggregated to individual 7705 SAR nodes. Each cell site has one or more Node Bs. The Node Bs are typically from the same vendor and deployed on a regional basis, and it is common for carriers to simplify provisioning by using the same VPI and VCI values for specific types of traffic handled at different cell sites.

Such a scenario applies, for example, to a service provider that deploys multiple Node Bs in a specific region to support voice, low-speed, and high-speed packet data. In this case, the 7705 SAR grooms the three traffic types from each of the node Bs onto the network. Each traffic type is transported over a dedicated VC as follows:

  1. circuit-switched VC for voice services
  2. packet-switched VC for low-bandwidth data services
  3. HSxPA VC for high-bandwidth data services

In this N-to-1 scenario where N = 1, three VCs and three ATM PWs are required for each Node B.

4.9.4.1.2. VPI/VCI Translation (N = 1)

Before traffic from different cell sites can be switched to an RNC, VPI and VCI translation may be required in order to uniquely identify the site and the far-end equipment. If overlapping VPI/VCI values, as described in Deployment Scenario for N = 1 Cell Mode Encapsulation, are not used, VPI/VCI translation is not necessary.

The endpoints of a PWE3 N-to-1 cell mode ATM VLL can be:

  1. ATM VCs—VPI/VCI translation is supported
    In this case, when the VPI/VCI used at the endpoints (NodeB endpoint and RNC endpoint) are different, the VPI/VCI value can be modified at the endpoint of the far-end PE node, before the cells are switched to the ATM interface.
  2. ATM VPs—VPI translation is supported (the VPI at each endpoint need not be the same, but the original VCI will be maintained)
    In this case, when the VPI and VCI used at the endpoints are different, only the VPI can be modified at the endpoint (VPI can only be changed by the far-end PE node, before the cells are switched to the ATM interface).

See VPI/VCI Translation for SAP Aggregation Group Members (N>1) for information about how VPI/VCI translation functions with N > 1 mode.

4.9.4.1.3. Cell Concatenation (N = 1)

The 7705 SAR supports the concatenation of ATM VP and VC cells into a pseudowire packet payload. Cells are packed on ingress to the VLL and unpacked on egress.

The number of cells in the payload of a single VLL packet is user-configurable, which ensures proper transport of traffic sensitive to delay and jitter. For example, for voice traffic in 3G/WCDMA, delay is a crucial factor and the time spent for concatenation should be minimized. The payload is extremely delay-sensitive and should be transported with only a small amount of bandwidth optimization.

In all cases, the number of cells in a VLL packet must be less than the MTU size, where the MTU maximum is 1514 bytes and the maximum N-to-1 mode payload is 29 cells (52 ATM bytes per cell (no HEC byte)).

While cells are being packed, the concatenation process may be terminated and the packet sent by any one of the following conditions. Each condition has a configurable attribute associated with it:

  1. reaching a maximum number of cells per packet
  2. expiring of a timer
  3. changing of the cell loss priority (CLP) bit

The CLP bits are untouched, even if VPI/VCI translation occurs at egress.

Note:

Configuring the attributes that provide the best compromise between minimizing delay (low number of cells concatenated) and maximizing bandwidth (high number of cells concatenated) requires careful planning.

4.9.4.1.4. QoS and Traffic Descriptor Profiles (N = 1)

QoS is configured on individual SAPs at ingress and egress using the SAP configuration hierarchy.

Individual SAPs support VC-based characteristics that include ingress and egress ATM (Layer 2) traffic descriptor profiles. Apipe rate-limiting on egress is controlled by the traffic-descriptor profile, not the QoS policy queue rates.

4.9.4.1.5. OAM (N = 1)

The ATM PW N-to-1 mode supports OAM operations in non-terminating mode for N = 1 services. The far-end PE node translates the incoming VPI/VCI values of the ATM OAM cells in the same way as the user data cells.

4.9.4.2. N-to-1 Cell Mode Encapsulation (N > 1)

The following sections describe ATM cell mode encapsulation where N > 1.

4.9.4.2.1. Deployment Scenario for N > 1 Cell Mode Encapsulation

N-to-1 mode where N >1 can be used by wireless service providers to optimize the PWs that are deployed in a network. By multiplexing the VCs of the same type that derive from different ATM base stations (Node Bs), the number of PWs can be decreased to one PW per service type.

With N-to-1 cell mode encapsulation where N > 1 traffic with the same characteristics and QoS requirements (such as delay, jitter, and loss) can be carried over the payload of a single ATM PW.

Figure 58 shows a typical network where N > 1 is deployed.

Figure 58:  VCC Cell Mode Encapsulation with N > 1  

4.9.4.2.2. PW Optimization (N > 1)

A network that uses a single PW for each type of traffic significantly reduces the number of ATM PWs that need to be configured to groom the traffic from multiple Node Bs. The result is a more efficient network backhaul configuration and traffic management strategy.

4.9.4.2.3. Overhead Optimization (N > 1)

A VC carrying signaling information between a Node B and an RNC must be configured with minimal packetization delay. N-to-1 cell mode encapsulation where N > 1 can be employed to:

  1. optimize the overhead associated with ATM PW headers because one PW packet header is used to transport multiple cells
  2. improve performance for delay and throughput efficiency

Typically, operators configure packetization delay to be 1 ms. Every 1 ms, an ATM PW packet is required to switch the signaling information from the 7705 SAR to the 7750 SR—regardless of the number of ATM cells that are received to transport signaling information. In most cases, the ATM PW packet carries very few ATM cells.

When signaling VCs from multiple Node Bs are mapped to the same ATM PW in N-to-1 fashion, the number of ATM cells that are received every 1 ms potentially increases. For example, if signaling from five Node Bs is aggregated for each ATM PW, a much larger number of ATM cells can be transported per ATM PW header.

4.9.4.2.4. Cell Concatenation (N > 1)

The maximum N-to-1 mode payload is 29 cells for N-to-1 cell mode where N > 1. This value applies to all of the SAPs that are members of the same SAP aggregation group. When the cell concatenation is configured for a specified number of cells, the 7705 SAR counts the cells it has received from all of the SAPs in the same SAP aggregation group and transmits the ATM PW packet when the limit is reached.

For example, for an ATM N >1 VCC service with four SAPs bound to the same SAP aggregation group, where the maximum number of cells for cell concatenation is set to 10, SAP1 might have 2 cells, SAP2 might have 5 cells, SAP3 might have 0 cells, and SAP4 might have 3 cells.

In all cases, the number of cells in a VLL packet must be less than the MTU size, where the MTU maximum is 1514 bytes and the maximum N-to-1 mode payload is 29 cells (52 ATM bytes per cell (no HEC byte)).

The max-delay configuration also applies at the SAP aggregation group level.

Note:

CLP change-based termination of payload concatenation is not supported for N > 1 cell mode.

4.9.4.2.5. OAM (N > 1)

The ATM PW N-to-1 mode supports OAM operations in non-terminating mode for N > 1 services. The 7705 SAR forwards the Layer 2 AIS cells that it receives from the SAP aggregation group SAPs over the PW. The 7705 SAR translates the incoming VPI/VCI values of the AIS cells in the same way as any other type of traffic.

4.9.4.2.6. Hardware Support for N > 1 Cell Mode Encapsulation

The following hardware supports N > 1 cell mode encapsulation:

  1. 16-port T1/E1 ASAP Adapter card
  2. 32-port T1/E1 ASAP Adapter card
  3. 7705 SAR-M (variants with T1/E1 ports)

4.9.4.2.7. SAP Support for N > 1

The SAP aggregation group can include SAPs on:

  1. different ATM ports
  2. different IMA ports
  3. a combination of ATM and IMA ports
Note:

All SAPs that are bound to the same N > 1 ATM PW must be configured on the same adapter card. An N > 1 ATM PW cannot span multiple adapter cards.

4.9.5. SAP Aggregation Groups

N > 1 cell mode encapsulation is implemented on the 7705 SAR using SAP aggregation groups. The following sections describe how to configure and manage SAP aggregation groups:

Note:

An Apipe can have either regular SAPs or SAPs that belong to SAP aggregation groups, but not both.

See Apipe Service with SAP Aggregation Configuration Commands for more information about the commands and parameters that are required to configure a SAP aggregation group.

4.9.5.1. Configuration

The following section describes the objects required to configure a SAP aggregation group and group members. See VLL Services Configuration Commands for more information.

4.9.5.1.1. Sap-aggregation-group Keyword

The sap-aggregation-group keyword is used to associate multiple SAPs with a single ATM VCC Apipe service. The SAP aggregation group is a high-level object under which general features are defined. These features include accounting, statistics, and the packet layer QoS profile. All common access parameters are configured under the sap-aggregation-group.

4.9.5.1.2. Sap-aggregation-group Group Identifier

The sap-aggregation-group group-id is used for two purposes:

  1. to identify a SAP aggregation group. The group-id is an alphanumeric identifier. For example:
         sap-aggregation-group group_id_1
  2. to identify a SAP as a member of an aggregation group. SAPs that are to be bound to the same ATM PW payload must be tagged with the same sap-aggregation-group group-id. For example:
         sap 1/2/3.1:3/300 sap-aggregation-group group_id_1

The sap-aggregation-group group-id can be up to 32 alphanumeric characters.

4.9.5.1.3. VPI/VCI Translation for SAP Aggregation Group Members (N>1)

The vcid-translation vpi/vci keyword is an optional configuration item that is used only for SAPs that are members of a SAP aggregation group. The vcid-translation vpi/vci keyword translates the VPI and VCI values of the incoming ATM cells before the cells are mapped to an ATM PW payload. That is, at ingress, the VPI/VCI values for a SAP that is a member of a SAP aggregation group are rewritten by the VPI/VCI values of the vcid-translation keyword.

In the reverse direction, when the 7705 SAR receives the cells with translated VPI/VCI values from its peer (such as a 7750 SR), another translation to SAP-configured VPI/VCI values is required before cells are sent to the SAP.

The vcid-translation keyword applies to user and OAM cells. When the vcid-translation keyword is configured, all cells are translated.

If the vcid-translation keyword is not configured for any ATM SAP aggregation group, the ingress VPI/VCI values are retained.

Note:

The 7705 SAR performs a check to ensure the uniqueness of the translated VPI/VCI values for all of the SAPs of the same ATM PW service, that is, within the same SAP aggregation group. If there are duplicate VC identifiers, the status of the VCs are set to operationally down and flagged as ApipeSapVcIdNotUnique. It is the sole responsibility of the user to ensure uniqueness of VPI/VCI values after translation.

4.9.5.2. QoS and Traffic Descriptor Profiles (N > 1)

Packet layer, N > 1 ATM PW QoS functions are configured using the SAP aggregation group hierarchy. The QoS profiles for ingress and egress are configurable for each N > 1 service. Any existing QoS profile can be applied to an N > 1 service. The QoS policy determines the QoS offering, including the classification and queuing for the whole PW, irrespective of the number of SAPs that are bound to the aggregated service.

Although a single SAP egress policy is configured for a SAP aggregation group, a separate egress queue is created for each SAP. The MBS and CBS values for each of these egress SAP queues are set to equal the MBS and CBS values configured in the SAP egress QoS policy for the SAP aggregation group. The SAP egress QoS policy causes n times the values of the CBS buffers to be committed, where n is the number of SAPs in the SAP aggregation group. Refer to the 7705 SAR Quality of Service Guide for more information.

Note:

ATM layer policing on individual SAPs within a SAP aggregation group is not supported. You cannot apply ATM QoS traffic descriptor profiles on ingress to a SAP in a SAP aggregation group; the profile is set to the default (1).

Rate-limiting on egress for aggregated SAPs is controlled by the ATM traffic-descriptor profile, not the QoS policy queue rates. Each SAP that is a member of a SAP aggregation group has its own egress Layer 2 traffic descriptors. These descriptors are used for shaping and scheduling priority at egress.

4.9.5.3. Statistics and Counters

The statistics for aggregation groups are maintained on a per-group basis. Statistics for SAP aggregation groups are available using the following commands:

  1. show service id n sap-aggregation-group group-id stats
  2. show service id n sap-aggregation-group group-id group-stats

The stats keyword shows statistics for the aggregation group on a per-queue basis. The group-stats keyword shows the SAPs that are members of a specified group and the corresponding SAP-level statistics, including aggregated queue statistics. See Show Commands for more information.

Because SAP aggregation groups can span multiple ports, the 7705 SAR does not support port-level packet and discard counters for N > 1 SAPs. When only N > 1 services are configured on an adapter card, the 7705 SAR shows a value of 0 for port packet and discard statistics.

Octet counters are available under each SAP group member. The port and bundle ATM PVC statistics are recorded for the SAPs in a SAP aggregation group. These statistics are helpful for debugging an individual SAP.

A statistics counter tracks all unconfigured or unknown VPI/VCI values that are received in an ATM PW payload from the network. The received VPI/VCI values are compared to the vcid-translation vpi/vci keyword values, and if a value is detected that does not match, the counter for unknown VPIs/VCIs is incremented. The values appear in the Dropped Egress Cells (unconfigured vpi/vci) field and are available using the show service id n all and show service id n sap-aggregation-group group-id detail commands. See Show Commands for more information.

The monitor service id n sap-aggregation-group group-id provides user-configurable controls for the interval and rate of statistics collection. Refer to the 7705 SAR Basic System Configuration Guide for more information.

Statistics are cleared using the clear service statistics sap sap-id and clear service statistics sap-aggregation-group group-id commands. The sap sap-id clears ATM Layer 2 counters; QoS counters are not applicable for SAPs that are members of an aggregation group. The sap-aggregation-group group-id clears network Layer 3 QoS queue statistics. See Clear Commands for more information.

4.9.5.4. Fault Management

A PW failure results in the transmission of a pw-status TLV message to the far-end node. If the 7705 SAR receives a pw-status TLV message, the 7705 SAR sends an AIS to all of the ATM SAPs.

If an individual SAP in a SAP aggregation group of an N > 1 service fails or is disabled, the 7705 SAR inserts OAM cells into the PW for the failing VC, using the translated VPI/VCIs. If all SAPs in a SAP aggregation group fail or are shut down, the 7705 SAR generates a pw-status TVL message that designates the SAP as sap-down.

In the case of a card failure for N = 1 and N > 1 services, if all the SAPs of the same service fail or if the service is shut down, the 7705 SAR transmits a pw-status TLV message to the far-end node. If the 7705 SAR receives a pw-status TLV from the far-end node (that is, a lacIngressFault or lacEgressFault), AIS messages are generated and sent to all of the SAPs that are part of the SAP aggregation group.

If a port fails, the 7705 SAR sends AIS cells over the ATM PW to the far-end node.

For end-to-end resiliency, an N > 1 ATM PW service supports PW redundancy.

4.9.6. QoS Policies

When applied to 7705 SAR Apipe, Cpipe, Epipe, and Ipipe services, service ingress QoS policies only create the unicast queues defined in the policy.

With Apipe, Cpipe, Epipe, and Ipipe services, egress QoS policies function as with other services where the class-based queues are created as defined in the policy.

Both Layer 2 and Layer 3 criteria can be used in the QoS policies for traffic classification in a Cpipe, Epipe, or Ipipe service. QoS policies on Apipes cannot perform any classification.

4.9.7. IP Filter Policies

The 7705 SAR supports IPv4 and IPv6 filter policies on the following entities:

  1. IPv4 ingress
    1. network interfaces
    2. Ethernet SAPs on all services
    3. ATM SAPs on a 4-port OC3/STM1 Clear Channel Adapter card in conjunction with bridged llc-snap ATM SAP to VPLS
    4. ATM SAPs on a 16- or 32-port T1/E1 ASAP Adapter card in conjunction with routed VC-Mux ATM SAP to IES
    5. FR and cHDLC SAPs on a 16- or 32-port T1/E1 ASAP Adapter card in conjunction with IP PWs
    6. FR SAPs on a 4-port DS3/E3 Adapter card in DS3, clear channel mode in conjunction with IP PWs
    7. V.35 and X.21 cHDLC SAPs on a 12-port Serial Data Interface card in conjunction with IP PWs
    8. spoke SDPs on VPLS, VPRN interfaces, and IES interfaces
    9. mesh SDPs on VPLS
  2. IPv4 egress
    1. network interfaces
    2. Ethernet SAPs on VPRN and IES interfaces
    3. Ethernet SAPs on VPLS
  3. IPv6 ingress and egress
    1. Ethernet network interfaces (with null or dot1q encapsulation)
    2. network interfaces on the 4-port OC3/STM1 Clear Channel Adapter card (with POS encapsulation)
    3. Ethernet SAPs on IES

Configuration and assignment of IP filter policies is similar for network interfaces, IES management SAPs, Ethernet and IP pseudowire SAPs, VPRN and IES SAPs and spoke SDPs, and VPLS SAPs and SDPs (spoke and mesh). Refer to the 7705 SAR Router Configuration Guide, “Filter Policies”, for information on configuring IP filters.

4.9.8. MTU Settings

There are several MTU values that must be set properly for a VLL service (Apipe, Cpipe, Epipe, Fpipe, Hpipe, or Ipipe) to work from end to end. Figure 59 locates the MTU point for each value. Table 33 describes the MTU points. The MTU points are:

  1. access port MTU
  2. SAP MTU
  3. service MTU
  4. path MTU
  5. network port MTU

In order for a VLL service to be declared “up” without any MTU-related error messages, the following rule must be true:

        SAP MTU ≥ Service MTU £ Path MTU

Figure 59:  MTU Points on the 7705 SAR 
Table 33:  MTU Points and Descriptions  

MTU Point

Description

Command

1

Access port MTU

The access port MTU value is a configurable value that accounts for the Layer 2 header and the payload. The default access port MTU value for the following Fast Ethernet port SAP encapsulations is:

  1. null: 1514 bytes (payload = 1500 bytes, L2 header = 14 bytes)
  2. dot1q: 1518 bytes (payload = 1500 bytes, L2 header = 18 bytes)
  3. qinq: 1522 bytes (payload = 1500 bytes, L2 header = 22 bytes)

mtu, under the config>port context, where the port type can be Ethernet, DSL, GPON, TDM, serial, or SONET/SDH

2

SAP MTU

The SAP MTU value is not a configurable value. It is set at the SAP by the 7705 SAR operating system. It defines the service payload capability of the service and is automatically set to be the same value as the access port MTU.

Not user-configurable

3

Service MTU

The service MTU value is a configurable value and is the same size as the VLL payload. The service MTU is sometimes called the VC-type MTU in the 7705 SAR documentation set. In Figure 59, NP stands for network processor.

For CESoPSN with CAS service, ensure that the service MTU is set to a value large enough to account for the extra bytes appended to the packet payload for CAS bits. See Structured T1/E1 CES with CAS for more information.

service-mtu, under the config>port context, where the port type can be Ethernet, DSL, GPON, TDM, serial, or SONET/SDH

IP MTU is specific to Layer 3 spoke-SDP termination. Layer 3 spoke-SDP termination can be configured for interfaces under IES and VPRN services. IP MTU is used to signal the service MTU of Layer 3-spoke SDP termination to a peer PE node.

ip-mtu, under the config>service> vprn or ies context for an interface

4

Path MTU

The path MTU is configured at the SDP. It is the maximum that the SDP can transmit without rejecting and discarding the packet. The path MTU value is derived from the network port MTU value by subtracting the Layer 2 and Layer 2.5 overhead values (for MPLS) and the Layer 2 and Layer 3 overhead values (for GRE).

If the network port SDP binding is Ethernet, then the following equations hold:

  1. For MPLS:
    Path MTU = Port MTU - (Ethernet header [14 bytes or 18 bytes or 22 bytes] + Tunnel header + PW header)
  2. For GRE:
    Path MTU = Port MTU - (Ethernet header [14 bytes or 18 bytes or 22 bytes] + IP header [20 bytes] + Tunnel header [4 bytes] + PW header [4 bytes])

path-mtu, under the config> service>sdp context

5

Network port MTU

The network port MTU is a configurable value equal to the payload plus all headers (L2, IP (for GRE), tunnel and PW), up to the maximum supported value (hardware limit) of 9728 bytes.

Same as access port MTU (above)

Table 34 displays the default, minimum, and maximum service MTU values for Ethernet ports. These values are dependent upon the port type, mode, encapsulation type, and service type.

Table 35 and Table 36 aid in calculating MTU values for various configurations and operating scenarios.

Table 34:  Service MTU Default and Maximum Values  

Port Type

Mode

Encap Type

Service Type

Service MTU (bytes)

Default

Minimum

Maximum (SAP to SDP)

Maximum (SAP to SAP)

10/100 Ethernet  1

Access

null, dot1q, qinq  3

Epipe, VPLS

1514

1

9670  2

9724  2

Ipipe

1500

GigE SFP  1

Access

null, dot1q, qinq  3

Epipe, VPLS

1514

1

9670  2

9724  2

Ipipe

1500

    Notes:

  1. The maximum MTU value is supported only on cards that have buffer chaining enabled; therefore, it is not supported on the 8-port Ethernet Adapter card, version 1.
  2. On the Packet Microwave Adapter card, the MWA ports support 4 bytes less than the Ethernet ports. Thus, MWA ports support a maximum MTU of 9720 bytes (null) or 9724 bytes (dot1q). MWA ports do not support QinQ.
  3. QinQ is supported only on access ports.

For more information on port MTU, refer to “MTU Configuration Guidelines” in the 7705 SAR Interface Configuration Guide.

Table 35:  MTU Calculator—Service Creation (Worst Case) Access Ports and SAPs 

Service Creation

Access Port Default MTU

SAP

TDM/ATM

Eth

Epipe

Ipipe

Apipe

Cpipe

Fpipe

Hpipe

Max Payload

9732

9732

1514

1514

2048

2048

RTP Header

12

Control Word

4

4

4

4

4

4

SDP Encap: GRE/MPLS

IP Header for

20

20

20

20

20

20

GRE/MPLS

4

4

4

4

4

4

PW Header

4

4

4

4

4

4

VCCV Type 2

4

4

4

4

4

4

Fast Reroute Label

LDP over RSVP

Physical Media (T1/E1 ASAP and Ethernet Adapter cards)

Eth Null

1514

Eth Dot1q

1518

Eth QinQ

1522

Eth Type

Eth-SA

Eth-DA

TDM/ATM

1572

1572

PPP Protocol

ML Sequence

ML Preamble

Total

9768

9768

1550

1562

2084

2084

Table 36:  MTU Calculator—Service Creation (Worst Case) Network Ports 

Service Creation

NW

Network Port Default MTU

Epipe over

MPLS Encap

Epipe/Ipipe

over GRE

LSR

PPP

ML/PPP

Eth Null

Eth Dot1q

MPLS

Label

Best Case

Worst

Case

Worst

Case

Max Payload

40

2048

2084

RTP Header

Control Word

4

SDP Encap: GRE/MPLS

IP Header for

20

GRE/MPLS

4

4

4

PW Header

4

4

VCCV Type 2

4

4

Fast Reroute Label

4

LDP over RSVP

4

Physical Media (T1/E1 ASAP and Ethernet Adapter cards)

Eth Null

Eth Dot1q

4

4

4

Eth QinQ

8

8

8

Eth Type

2

2

2

2

Eth-SA

6

6

6

6

Eth-DA

6

6

6

6

TDM/ATM

PPP Protocol

2

2

2

ML Sequence

3

ML Preamble

1

Total

2

6

14

26

50

2110

2114

Note:

  1. In order to accommodate current and future services (including overhead), the MTU values for Gigabit Ethernet and PPP/MLPPP ports have the default value set to 1572 bytes. For 10/100 Ethernet ports, the MTU value is set to 1514 or 1518 or 1522 bytes, depending on the encapsulation setting (null or dot1q or qinq).
  2. The default service MTU value is 1514 bytes; the maximum value is 1522 bytes.

4.9.8.1. Targeted LDP and MTU

The extended discovery mechanism for Label Distribution Protocol (LDP) sends LDP Targeted Hello messages to a specific address. This is known as targeted LDP or T-LDP. Refer to RFC 5036 for detailed information about the extended discovery mechanism.

During the VLL service creation process (that is, using targeted LDP signaling), the MTU or payload size of a service is signaled to the far-end peer. MTU settings at both ends (near and far peers) must match in order for the VLL service to operate. Table 37 shows the values that are expected to match.

Table 37:  Matching MTU or Payload Values for Signaled VLL Services 

Apipe

Cpipe

Epipe

Fpipe

Hpipe

Ipipe

Payload size (bytes)

Yes

Bit rate

Yes

Maximum number of ATM cells

Yes

Service MTU

Yes

Yes

Yes

Yes

Must match at both ends

Yes

Yes

Yes

Yes

Yes

Yes

4.9.9. QinQ (VLL Service)

Epipe and Ipipe VLL services support QinQ functionality. For details, see QinQ Support.

4.9.10. Pseudowire Control Word

The PW control word (CW) is a 32-bit field that is inserted between the VC label and the Layer 2 frame. The presence of the control word is indicated by the C bit of the FEC element used in LDP signaling. The PW control word is described in RFC 4385.

The PW control word is supported for all implemented PW types (ATM N-to-1 cell mode, Ethernet VLLs, SAToP, CESoPSN, FR PW, HDLC PW, and IP PW). The control word must be used for any pseudowire service that transports packets that are less than 64 bytes; see the control-word command description for more information.

The following points describe the behavior of the 7705 SAR when it receives a Label Mapping message for a PW. It is assumed that no Label Mapping message for the PW has been sent to the next PW router yet. The 7705 SAR operating system does the following.

  1. If the received Label Mapping message has C = 0 (where C refers to the C bit of the FEC element), a Label Mapping message with C = 0 is sent forward to the next router (or hop). In this case, the control word is not used.
  2. If the received Label Mapping message has C = 1 and the PW is locally configured such that the use of the control word is mandatory, then the 7705 SAR sends a Label Mapping message with C = 1. In this case, the control word is used. (Note: SAToP and CESoPSN are the only services that require the control word.)
  3. If the received Label Mapping message has C = 1 and the locally configured PW does not support use of an optional control word (that is, Ethernet or ATM N-to-1 cell mode PWs), then the 7705 SAR sends a new Label Mapping message in which the C bit is set to correspond to the locally configured preference for use of the control word (that is, C = 0).

4.9.11. Pseudowire Redundancy

Pseudowire (PW) redundancy protects a PW and any services on the PW against endpoint failures. This differs from LSP redundancy and FRR, which offer protection against link and node failures within the backhaul network.

As shown in Figure 60, in order to provide redundant PWs, the 7705 SAR must signal PWs to two endpoints at the MTSO (7x50-1 and 7x50-2), which is done using two spoke SDPs on the 7705 SAR. This configuration removes any single point of failure from a given network. If 7x50-1 loses all of its connectivity to the network or to the RNC, then the 7705 SAR can reroute the PW traffic to 7x50-2, which switches traffic to the RNC.

For end-to-end protection, PW redundancy is supported in the following scenarios:

  1. PW redundancy with multi-chassis LAG (MC-LAG)/multi-chassis APS (MC-APS)
  2. PW redundancy with VPLS or PW switching

For more information on MC-APS, refer to the 7705 SAR Interface Configuration Guide, “Automatic Protection Switching”. For more information on MC-LAG, refer to the SAR OS Interface Configuration Guide, “Multi-Chassis LAG”.

Figure 60:  Pseudowire Redundancy 

PW redundancy applies to all VLL services available on the 7705 SAR: Apipe, Cpipe, Epipe, Fpipe, Hpipe, and Ipipe.

4.9.11.1. PW Redundancy Operation

PW redundancy on the 7705 SAR is similar to a point-to-multipoint implementation for PWs (in the ingress to the egress direction). A single SAP can be bound to more than one spoke SDP, and traffic from multiple spoke SDPs can all be switched to the same SAP. To implement PW redundancy, a PW service on the 7705 SAR must be able to accommodate more than one spoke SDP on the spoke SDP side. This is achieved using the concept of endpoints.

An endpoint can be thought of as a container for a single SAP, a single spoke SDP, or multiple spoke SDPs. Figure 61 illustrates the model for a redundant VLL service based on the endpoints. Endpoints are implicit or explicit objects.

Implicit endpoints are transparent to the user and are not user-configurable. As shown in Figure 61a, implicit endpoints mean that one endpoint is a SAP and another endpoint is a spoke SDP. Endpoints are considered implicit if the endpoint command is not used in the config>service>xpipe>spoke-sdp context, where xpipe refers to any of the VLL services.

Explicit endpoints are user-configurable and apply when there are multiple spoke SDPs. As shown in Figure 61b, explicit endpoints mean that there can be multiple spoke SDPs associated with the endpoint. An endpoint created explicitly can have up to four spoke SDPs associated with it. The explicit endpoint method is used for PW redundancy. Explicit endpoints are user-configurable.

Figure 61:  Implicit and Explicit Endpoint Objects 

The 7705 SAR supports the following types of endpoint objects:

  1. SAP—there can be only one SAP per PW endpoint (Endpoint X in Figure 61a)
  2. Spoke SDP—from the perspective of a 7705 SAR, if there is only one SDP endpoint, then it is a spoke SDP endpoint and it is implicitly defined. In other words, there can be only one implicitly defined spoke SDP per PW endpoint (Endpoint Y in Figure 61a).
  3. Primary spoke SDP—there can be only one explicitly defined primary spoke SDP per PW endpoint (one of the spoke SDPs at Endpoint Z in Figure 61b). If a primary spoke SDP is defined, then there can be up to three secondary spoke SDPs per endpoint and the service can be revertive.
  4. Secondary spoke SDP—there can be up to four explicitly defined secondary spoke SDPs per endpoint if no primary spoke SDP is defined; otherwise, there can be up to three. Secondary spoke SDPs are assigned a precedence value that is used by the 7705 SAR to determine which secondary PW becomes active when the currently active PW fails (see Selecting the Active Spoke SDP for PW Redundancy Configuration).

Multiple spoke SDPs can be established between a 7705 SAR and any SR platform. For example, multiple spoke SDPs on a 7705 SAR can connect to a 7750 SR. In this case, the 7750 SR must be configured to use multi-chassis backup in conjunction with multi-segment PWs; that is, the 7750 SR nodes at the far end must support multi-chassis redundancy.

A PW service endpoint can only use a single active spoke SDP for transmission at any given time. A PW SAP can receive traffic from any of the endpoint spoke SDPs assigned to the service.

7705 SAR nodes support user-initiated manual switchover of the VLL path to the primary path or any of the secondary paths using the force-switchover command under the tools>perform>service-id context. A manual switchover is useful during planned outages such as node upgrade procedures.

4.9.11.2. Selecting the Active Spoke SDP for PW Redundancy Configuration

There are two main scenarios for configuring PW redundancy. One scenario uses a primary spoke SDP and provides revertive behavior. The other scenario uses only secondary spoke SDPs for non-revertive behavior.

Note:

Non-revertive behavior is not supported on Cpipes.

4.9.11.2.1. Primary and Secondary Spoke SDPs

If a primary spoke SDP is defined, up to three secondary spoke SDPs can also be defined. The VLL service always uses the primary endpoint PW and only switches to a secondary PW when the primary PW is down. The PW service switches the path back to the primary PW when the primary PW is back up. The user can configure a timer to delay reverting back to the primary path or to never revert back. When the primary PW goes down, the 7705 SAR selects the secondary spoke SDP that is operationally up and has the highest precedence setting.

4.9.11.2.2. Secondary Spoke SDPs Only

If a primary spoke SDP is not defined, up to four secondary spoke SDPs can be defined. The user can configure the precedence of each secondary PW to indicate the order in which secondary PWs are activated. The secondary PW with the highest precedence is selected first. If two or more secondary spoke SDPs are assigned the same precedence, the 7705 SAR selects the secondary path that is operationally up and has the lowest spoke SDP identifier. There is no revertive behavior between secondary paths, which means that a secondary path will not switch to another secondary path of higher precedence if one becomes available.

The use of four secondary spoke SDPs is illustrated in Figure 62, where:

  1. spoke SDP-1 goes over S-PE-1 to T-PE1 (red path) (S-PE is a switching PE and T-PE is a terminating PE)
  2. spoke SDP-2 goes over S-PE-1 to T-PE2 (green path)
  3. spoke SDP-3 goes over S-PE-2 to T-PE1 (violet path)
  4. spoke SDP-4 goes over S-PE-2 to T-PE2 (orange path)

.

Figure 62:  Pseudowire Redundancy with Four Spoke SDPs 

4.9.11.3. PW Redundancy and Inter-Chassis Backup

ICB (Inter-Chassis Backup) spoke SDPs are supported for use with Cpipe services in an MC-APS configuration and with Epipe services in an MC-LAG configuration. ICB improves switch times, provides additional protection in case of network failures, and reduces packet loss when an active endpoint is switched from a failed MC-APS or MC-LAG node to a protection node.

An MC-APS or MC-LAG switchover consists of two switchovers, first on the access side and then on the network side. A failure on the access side (an MC-APS or MC-LAG switchover), triggers a network-side (pseudowire) switchover. However, a pseudowire switchover does not trigger an MC-APS or MC-LAG switchover.

Figure 63 shows a network experiencing an access side failure.

Figure 63:  Access Side Failure with ICB Protection 

If the active access link of an MC-APS or MC-LAG group fails, the MC-APS or MC-LAG protocol causes the access side to switch to the protection (standby) link. If ICB is configured, the in-flight packets coming from the network side will be sent over the ICB to the newly active access link. Shortly after the access-side switchover, pseudowire redundancy causes the network side to switch as well. In this scenario, ICB reduces the switch time by carrying the in-flight packets during the access and network switchovers.

Figure 64 shows a network experiencing a network side failure.

Figure 64:  Network Side Failure with ICB Protection 

If the active network link of an MC-APS or MC-LAG group fails, pseudowire redundancy causes the network side to switch to the standby pseudowire. This does not trigger an MC-APS or MC-LAG switchover. If there is no ICB, then the end-to-end transmission will be lost as the access link never switches. If ICB is configured, the packets coming in from the newly active network link are sent across the ICB to the active access side and vice versa. In this scenario, ICB provides protection against network failures.

An endpoint can have only one ICB spoke SDP, which must be identified as ICB in the spoke-sdp command. If an ICB spoke SDP is added to an endpoint, then a SAP can be added only if it is part of an MC-LAG or MC-APS group. Similarly, if an MC-LAG or MC-APS SAP is added to an endpoint, the only other possible addition to that endpoint is an ICB spoke SDP.

4.9.11.4. AIS Fault Propagation

When the 7705 SAR is operating in an MPLS network with TDM pseudowires using PW redundancy, it can interoperate with SDH networks that use subnetwork connection protection (SNCP). SNCP is a path-based protection mechanism for T1/E1 services. When the 7705 SAR interoperates with SDH networks that use SNCP, it can make PW redundancy switching decisions based on SDH signaling, which keeps the active data paths in the SDH and the MPLS networks synchronized.

This functionality is only available on unframed E1 channels and unframed DS1 channels on the following cards:

  1. 2-port OC3/STM1 Channelized Adapter card
  2. 4-port OC3/STM1 / 1-port OC12/STM4 Adapter card

If SNCP-protected equipment detects a failure in an SDH network, it inserts an AIS into the TU-12 overhead of the SDH frame so that the appropriate activity switch can occur in the SDH network. When the 7705 SAR detects a TU12-AIS for a specific VC-12 path in an SDH network and AIS propagation is enabled using the command config>card>mda>ais-propagation, the 7705 SAR generates a TU12-AIS for the corresponding VC-12 at the other end of the Cpipe. If the VC-12 path is involved in PW redundancy, a PW activity switch occurs, which signals the SDH node to do an SNCP switch.

4.9.12. Active/Standby Mode for Pseudowire Redundancy (Standby Signaling)

Pseudowire redundancy as described in the previous section operates in active/active mode; that is, the primary pseudowire is up and ready to transmit and receive traffic, and the secondary pseudowire is up and ready to receive traffic. In Figure 65, if both pseudowires were active, this mode of operation would offer seamless redundancy in most cases. However, this mode could also potentially stress the IGP; for example, in active/active mode the number of routes advertised is greater than in active/standby mode. Another example is the duplication of Ethernet control frames to the 7705 SAR from a VPLS or VPRN service on an SR node through both primary and secondary VLLs.

Figure 65:  Active/Standby Mode for Redundant Pseudowires 

Active/standby mode is introduced to address these issues. Active/standby mode is also referred to as standby signaling. Standby signaling is supported on all VLLs: Apipes, Cpipes, Epipes, Ipipes, Fpipes, and Hpipes.

Standby signaling has two components: standby-signaling master and standby-signaling slave. Figure 66 shows an example where standby-signaling-master has been enabled on the 7705_MTU node. A Cpipe has been configured between the 7705_MTU and the 7705_A node and between the 7705_MTU and the 7705_B node. The spoke SDP towards 7705_A is the active PW (precedence primary), while the spoke SDP towards 7705_B is the standby PW (precedence 1).

An example of the CLI syntax to configure the 7705_MTU is:

CLI Syntax:
config>service# cpipe 555 customer 1 vc-type cesopsn create
endpoint “stdbyMaster” create
standby-signaling-master
exit
spoke-sdp 5:555 endpoint “stdbyMaster” create
precedence 1
exit
spoke-sdp 131:555 endpoint “stdbyMaster” create
precedence primary
exit
Figure 66:  Standby-signaling-master Enabled 
Note:

Standby-signaling-master should be enabled on only one endpoint of the pseudowire; otherwise, the pseudowire could bounce.

Traffic passes over the active PW. If the status of the active PW changes, the standby PW becomes active and starts passing traffic.

Because the 7705_MTU is configured for standby-signaling-master, the standby PW sends its status to the far end by sending a standby bit over T-LDP. However, the receiving end (in Figure 66, 7705_B) ignores the bit and continues to transmit data towards the 7705_MTU as long as the PW is up; therefore, pseudowire redundancy does not work.

In order to stop data from being transmitted along standby spoke SDPs, the far-end endpoints must be enabled for standby-signaling-slave. Figure 67 shows a scenario where 7705_A and 7705_B have been enabled for standby-signaling-slave.

An example of the CLI syntax to configure the 7705_A and 7705_B nodes is:

CLI Syntax:
config>service# cpipe 555 customer 1 vc-type cesopsn create
endpoint “FarendA” create
standby-signaling-slave
exit
spoke-sdp 130:555 endpoint “FarendA” create
precedence primary
exit
CLI Syntax:
config>service# cpipe 555 customer 1 vc-type cesopsn create
endpoint “FarendB” create
standby-signaling-slave
exit
spoke-sdp 130:555 endpoint “FarendB” create
precedence primary
exit
Figure 67:  Standby-signaling-slave Enabled 

With standby-signaling-slave enabled, when the standby PW sends the standby bit to the far end over T-LDP, the SDP flags bit is set to block traffic being transmitted back to the 7705_MTU (flags bit is set to StandbySigSlaveTxDown). The spoke SDP remains up. If the standby PW becomes active, the flags bit is reset and traffic resumes on the PW.

Note:

Standby-signaling-master and standby-signaling slave cannot be enabled at the same time on the same endpoint.

4.9.12.1. PW Status Signaling Label Withdrawal Option

The 7705 SAR supports PW status signaling or label withdrawal for signaling PW status.

Signaling PW status based on label withdrawal requires the PW label to be released, whereas PW status signaling can mark the PW as unusable based on local-end and far-end status and on status messages exchanged between endpoints.

As indicated in RFC 4447, Pseudowire Setup and Maintenance Using the Label Distribution Protocol, PW status signaling is the preferred method for exchanging state information between two endpoints and should be used as long as both endpoints support it.

However, the PW label withdrawal method for exchanging PW status can be configured even if the far end supports PW status signaling and the PW status TLV for designating the operational (forwarding) state of a PW.

This configuration option allows the PEs at both ends of the spoke SDP to use PW label withdrawal rather than the PW status TLV. This is necessary when a 7705 SAR must interoperate with PEs that do not support the PW forwarding standby bit, or when multiple remote PEs are connected to an r-VPLS instance via spoke-SDP termination.

4.9.12.1.1. Interoperation with PEs that do not Support the PW Forwarding Standby Bit

Not all PEs support the PW forwarding standby bit as part of pseudowire status signaling. If standby-signaling-master is enabled on the 7705 SAR, then it signals standby on all but one of the PWs, and blocks the transmit direction for all standby PWs. However, if a PE does not support processing of that bit, it will not block its end of the PW and will forward traffic onto that PW. As a result, traffic received on a standby PW at the 7705 SAR end is forwarded to the associated SAP. Master-slave PW redundancy prevents this from occurring only if all of the PEs support PW active/standby mode in a master-slave configuration and block their transmit directions for the standby PW. Previously, the 7705 SAR only used the PW label withdrawal method if a PE did not support the PW status signaling bit.

In order to allow PW redundancy on the 7705 SAR to interoperate with third party PEs that do not support the PW forwarding standby bit, an option to disable PW status signaling is provided. This will ensure that forwarding on a standby PW will be bidirectionally blocked in order to prevent PWs in standby mode from transmitting traffic via label withdrawal.

4.9.12.1.2. Multiple Remote PEs Connected to an r-VPLS Instance Via Spoke-SDP Termination

When multiple remote PEs are hooked up to an r-VPLS instance via spoke-SDP termination, label withdrawal can be used to control the operational status of the associated IP interface at the r-VPLS. If all of the spoke SDPs of an r-VPLS enter the forwarding standby state, the spoke SDP is locally blocked if the no ignore-standby-signaling option is configured. In its default mode of operation, the 7705 SAR automatically negotiates the use of PW status signaling on the spoke SDP. This means that a standby spoke SDP will not go operationally down at the endpoint. As a result, there is no change in the operational status of the VPLS to which the spoke SDPs are bound, and consequently, no change to the operational status of the r-VPLS or the IP interface.

The ability to disable PW status signaling makes it possible to configure the use of PW label withdrawal on a node, rather than allowing the automatic negotiation of PW status signaling. When pseudowire status signaling is disabled, a 7705 SAR does not include the PW status TLV in the initial label mapping message of the pseudowire that is used for a spoke SDP. This forces both 7705 SAR nodes to use the pseudowire label withdrawal method for exchanging pseudowire status. When the remote endpoint determines that a particular PW should be in standby mode, it will withdraw the PW label. This causes VPLS to go operationally down if the label is withdrawn for all PWs on a VPLS. The IP interface associated with r-VPLS goes down as a result.

4.9.12.2. Pseudowire Redundancy on Serial Data Interface Ports

Pseudowire redundancy is only supported on serial data interface ports when there is a Cpipe on a standby-signaling master with a single SAP and a endpoint with up to two spoke SDPs. The far-end slaves (standby-signaling slaves) each have a single SAP and a single spoke SDP back to the master.

Subrate speeds (< 64 kb/s) on RS-232 and X.21 ports are supported using HCM. HCM cannot determine signal quality until a circuit is established (that is, both endpoints of the circuit are connected); therefore, when standby-signaling-slave is enabled on subrate circuits, HCM framing will always be down on the inactive slave. The normal behavior is for the slave to send the port status to the master using the pseudowire status bit, indicating local attachment circuit (LAC) Tx/Rx faults. Because the slave cannot clear these faults, this prevents the master from switching back to the primary pseudowire as soon as possible (pseudowire redundancy reversion).

To enable pseudowire redundancy reversion in this case, the sending of LAC Tx/Rx fault messages from the slaves to the master is suppressed on RS-232 and X.21 ports configured for subrate speeds. The master is therefore not aware that the far-end port is down due to HCM being down and will switch back to the primary pseudowire as soon as other types of alarms are cleared.

These limitations apply to:

  1. RS-232 and X.21 ports on the 12-port Serial Data Interface card
  2. RS-232 ports on the 4-port T1/E1 and RS-232 Combination module (on the 7705 SAR-H)
  3. RS-232 ports on the 7705 SAR-Hc