3. 7705 SAR Interfaces

This chapter provides information about configuring chassis slots, cards, and ports.

Topics in this chapter include:

3.1. Configuration Overview

This guide uses the term “preprovisioning” in the context of preparing or preconfiguring entities such as chassis slots, the IOM, adapter cards, ports, and interfaces, prior to hardware actually being installed in the chassis. These entities can be installed but not enabled. When the entity is in a no shutdown state (administratively enabled), the entity is considered to be provisioned.

Nokia 7705 SAR routers provide the capability to configure chassis slots to accept specific adapter card types and set the relevant configurations before the equipment is actually installed. The preprovisioning ability allows you to plan your configurations as well as monitor and manage your router hardware inventory. Ports and interfaces can also be preprovisioned. When the functionality is needed, the cards can be inserted into the appropriate chassis slots as required.

The following sections are discussed:

3.1.1. Configuring the IOM and Card Slot

The 7705 SAR card slot ID is always 1 and the card type for the IOM is always iom-sar.

On the 7705 SAR-8 and 7705 SAR-18, the CSM, which can only be installed in slot A or B of the chassis, does not need to be provisioned. However, the IOM, which is virtualized in the 7705 SAR software, must be activated before the adapter cards, ports, and SCADA bridges can be preprovisioned and configured. The IOM is activated by designating it a card slot ID and card type. This enables the chassis slots to accept the adapter cards.

Note:

On the 7705 SAR-8, the CSM is called the CSMv2; both terms are used interchangeably in these guides. The CSMv2 supports bandwidth of 10 Gb/s, 2.5 Gb/s and 1 Gb/s in the first two adapter card slots and 2.5 Gb/s and 1 Gb/s in the remaining four adapter card slots. Support for 2.5 Gb/s and 10 Gb/s adapter cards by the CSMv2 is only available on the 7705 SAR-8 Shelf V2.

The 7705 SAR-M (all variants), 7705 SAR-H, 7705 SAR-Hc, 7705 SAR-A (both variants), 7705 SAR-Ax, 7705 SAR-W, 7705 SAR-Wx (all variants), and 7705 SAR-X have a fixed physical configuration and each router uses only one control and switching functional block, which is referred to on the CLI as CSM A. The CSM and IOM do not need to be provisioned in order to provision the interface at the adapter card level.

The slot ID (1) is used as part of the adapter card and port identifier on the CLI.

3.1.2. Configuring Adapter Cards and Modules

This section contains information on the following topics:

3.1.2.1. Provisioning Chassis Slots for Adapter Cards

A chassis slot and card type must be specified and provisioned before an adapter card can be provisioned. A chassis slot is a physical slot designated with an MDA ID. On the 7705 SAR-8, the MDA ID is from 1 to 6. On the 7705 SAR-18, the MDA ID is from 1 to 12 for the MDA slots and from X1 to X4 for the XMDA slots. An adapter card is provisioned when a card designated from the allowed adapter card types is inserted. A preprovisioned adapter card slot can remain empty without conflicting with populated slots.

The adapter cards can be installed in the chassis in any combination that does not exceed the maximum number. However, network applications require at least one network-capable adapter card to be installed as part of the mix.

Once installed and enabled, the system verifies that the installed adapter card type matches the configured parameters. If the parameters do not match, the adapter card remains offline.

3.1.2.2. Maximum Number of Adapter Cards in a Chassis

Note:

Unless otherwise specified, references to adapter cards with multiple versions include all versions of the cards.

A maximum of six adapter cards can be installed in the 7705 SAR-8 chassis. The following adapter cards are supported:

  1. 2-port 10GigE (Ethernet) Adapter card (maximum of 4 in a 7705 SAR-8 with CSMv2)
  2. 2-port OC3/STM1 Channelized Adapter card (maximum of 6, depending on channelization and CSM variant installed – see note below)
  3. 4-port OC3/STM1 / 1-port OC12/STM4 Adapter card (maximum of 6 in a 7705 SAR-8 with CSMv2)
  4. 4-port OC3/STM1 Clear Channel Adapter card (maximum of 6)
  5. 4-port DS3/E3 Adapter card (maximum of 6, depending on channelization and CSM variant installed – see note below)
  6. 6-port E&M Adapter card (maximum of 6)
  7. 6-port FXS Adapter card (maximum of 6)
  8. 6-port Ethernet 10Gbps Adapter card (maximum of 6 in a 7705 SAR-8 Shelf V2 with CSMv2 only)
  9. 8-port Ethernet Adapter card (maximum of 6)
  10. 8-port FXO Adapter card (maximum of 6)
  11. 8-port Gigabit Ethernet Adapter card (maximum of 6)
  12. 8-port Voice & Teleprotection card (maximum of 6)
  13. 8-port C37.94 Teleprotection card (maximum of 6)
  14. 12-port Serial Data Interface card (maximum of 6)
  15. 16-port T1/E1 ASAP Adapter card (maximum of 6)
  16. 32-port T1/E1 ASAP Adapter card (maximum of 6)
  17. Auxiliary Alarm card (maximum of 6)
  18. CWDM OADM Adapter card (maximum of 6)
  19. Integrated Services card (maximum of 6)
  20. Packet Microwave Adapter card (maximum of 6)
  21. Power Injector card (maximum of 4)

A maximum of 12 MDA adapter cards and 4 XMDA adapter cards can be installed in the 7705 SAR-18 chassis. The following adapter cards are supported:

  1. 2-port 10GigE (Ethernet) Adapter card (maximum of 6)
  2. 2-port OC3/STM1 Channelized Adapter card (maximum of 12, depending on channelization – see note below)
  3. 4-port OC3/STM1 / 1-port OC12/STM4 Adapter card (maximum of 12)
  4. 4-port OC3/STM1 Clear Channel Adapter card (maximum of 12)
  5. 4-port DS3/E3 Adapter card (maximum of 12, depending on channelization – see note below)
  6. 6-port E&M Adapter card (maximum of 12)
  7. 6-port FXS Adapter card (maximum of 12)
  8. 6-port Ethernet 10Gbps Adapter card (maximum of 12)
  9. 8-port Ethernet Adapter card, version 2 (maximum of 12)
  10. 8-port FXO Adapter card (maximum of 12)
  11. 8-port Gigabit Ethernet Adapter card (maximum of 12)
  12. 8-port Voice & Teleprotection card (maximum of 12)
  13. 8-port C37.94 Teleprotection card (maximum of 6)
  14. 10-port 1GigE/1-port 10GigE X-Adapter card (maximum of 4)
  15. 12-port Serial Data Interface card (maximum of 12)
  16. 16-port T1/E1 ASAP Adapter card, version 2 (maximum of 12)
  17. 32-port T1/E1 ASAP Adapter card (maximum of 12)
  18. Auxiliary Alarm card (maximum of 12)
  19. CWDM OADM Adapter card (maximum of 12)
  20. Integrated Services card (maximum of 12)
  21. Packet Microwave Adapter card (maximum of 12)
  22. Power Injector card (maximum of 8)
Note:

  1. On a 7705 SAR-8 chassis with a CSMv2:
    1. a maximum of six 2-port OC3/STM1 Channelized Adapter cards can be installed in MDA slots 1 to 6 if DS3 channelization is being used. If DS1/E1 or DS0 (64 kb/s) channelization is being used, a maximum of four 2-port OC3/STM1 Channelized Adapter cards can be installed in MDA slots 1 to 6.
    2. a maximum of six 4-port DS3/E3 Adapter cards can be installed in MDA slots 1 to 6 if DS3/E3 or DS1/E1 channelization is being used. If DS0 (64 kb/s) channelization is being used, a maximum of four 4-port DS3/E3 Adapter cards can be installed in MDA slots 1 to 6.
    3. a maximum of six 4-port OC3/STM1 / 1-port OC12/STM4 Adapter cards can be installed in MDA slots 1 to 6 if DS1/E1 channelization is being used. DS0 and DS3/E3 channelization is not supported on the 4-port OC3/STM1 / 1-port OC12/STM4 Adapter card.
    4. a maximum of six 6-port Ethernet 10Gbps Adapter cards can be installed in MDA slots 1 to 6. When installed in MDA slot 1 or 2, the 6-port Ethernet 10Gbps Adapter card supports a 10-Gb/s fabric rate. When installed in MDA slots 3 through 6, the aggregate fabric rate is 2.5 Gb/s.
  2. On a 7705 SAR-18 chassis:
    1. a maximum of twelve 2-port OC3/STM1 Channelized Adapter cards can be installed in MDA slots 1 to 12 if DS3 channelization is being used. If DS1/E1 or DS0 (64 kb/s) channelization is being used, a maximum of four 2-port OC3/STM1 Channelized Adapter cards can be installed in MDA slots 1 to 12.
    2. a maximum of twelve 4-port DS3/E3 Adapter cards can be installed in MDA slots 1 to 12 if DS3/E3 or DS1/E1 channelization is being used. If DS0 (64 kb/s) channelization is being used, a maximum of four 4-port DS3/E3 Adapter cards can be installed in MDA slots 1 to 12.
    3. a maximum of twelve 4-port OC3/STM1 / 1-port OC12/STM4 Adapter cards can be installed in MDA slots 1 to 12 if DS1/E1 channelization is being used. DS0 and DS3/E3 channelization is not supported on the 4-port OC3/STM1 / 1-port OC12/STM4 Adapter card.
  3. The total number of channel groups that can be configured per card and per node is bound by release-specific system limits. For more information, please contact your Nokia technical support representative.
Note:

Because the 6-port E&M Adapter card, 12-port Serial Data Interface card, 8-port Voice & Teleprotection card, 8-port C37.94 Teleprotection card, 8-port FXO Adapter card, and 6-port FXS Adapter card support access mode only, and the Integrated Services card is a resource card that supports an access functionality only, for network applications, the maximum number of each of these adapter cards that can be installed in a 7705 SAR-8 chassis is 5, and the maximum number that can be installed in a 7705 SAR-18 chassis is 11.

3.1.2.3. Evolution of Ethernet Adapter Cards, Modules, and Platforms

The 7705 SAR hardware components have improved as technology has developed. Table 2 lists the Ethernet adapter cards, modules, and platforms according to their generation. Second-generation (Gen-2) components have additional features, increased card memory and/or improved QoS mechanisms over first-generation (Gen-1) components. Similarly, third-generation (Gen-3) components improve upon second-generation components.

Table 2:  Ethernet Adapter Card, Module, and Platform Generations 

Generation

Card, Module, and Platform

First Generation

8-port Ethernet Adapter card

Second Generation

2-port 10GigE (Ethernet) Adapter card (v-port)

2-port 10GigE (Ethernet) module (v-port) (for 7705 SAR-M)

8-port Gigabit Ethernet Adapter card

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

Packet Microwave Adapter card

7705 SAR-A

7705 SAR-Ax

7705 SAR-H

7705 SAR-Hc

7705 SAR-M

7705 SAR-W

7705 SAR-Wx

4-port SAR-H Fast Ethernet module

6-port SAR-M Ethernet module

Third Generation

6-port Ethernet 10Gbps Adapter card

7705 SAR-X

3.1.2.4. Channelized Adapter Card Support

The following cards and modules support channelization down to the DS0 level:

  1. 16-port T1/E1 ASAP Adapter card
  2. 32-port T1/E1 ASAP Adapter card
  3. 12-port Serial Data Interface card
  4. 6-port E&M Adapter card
  5. 2-port OC3/STM1 Channelized Adapter card
  6. 4-port DS3/E3 Adapter card
  7. 8-port Voice & Teleprotection card
  8. 8-port C37.94 Teleprotection card
  9. 8-port FXO Adapter card
  10. 6-port FXS Adapter card
  11. 4-port T1/E1 and RS-232 Combination module

On the 16-port T1/E1 ASAP Adapter card, 32-port T1/E1 ASAP Adapter card, 2-port OC3/STM1 Channelized Adapter card, and 4-port DS3/E3 Adapter card (DS3 ports only), and on the T1/E1 ports of the 4-port T1/E1 and RS-232 Combination module, up to 24 channel groups are supported on a DS1 circuit and up to 32 channel groups on an E1 circuit.

The 12-port Serial Data Interface card supports a single channel group on a channelized V.35 circuit, RS-530, RS-232 (also known as EIA/TIA-232) circuit, or X.21 circuit. The RS-232 ports on the 4-port T1/E1 and RS-232 Combination module also support a single channel group on a channelized RS-232 circuit.

The 6-port E&M Adapter card supports a single channel group on a channelized E&M voice interface.

The 8-port Voice & Teleprotection card supports a single channel group on a channelized G.703 (codirectional) circuit, an IEEE C37.94 teleprotection interface (TPIF) circuit, FXS circuit, or FXO circuit.

The 8-port C37.94 Teleprotection card supports a single channel group on an IEEE C37.94 teleprotection interface (TPIF) circuit.

The 8-port FXO Adapter card supports a single channel group on an FXO circuit.

The 6-port FXS Adapter card supports a single channel group on an FXS circuit.

The 4-port OC3/STM1 / 1-port OC12/STM4 Adapter card supports channelization at the DS1/E1 level only.

3.1.2.4.1. PPP Over Fractional T1/E1

The 16-port T1/E1 ASAP Adapter card, 32-port T1/E1 ASAP Adapter card, and the T1/E1 ports on the 4-port T1/E1 and RS-232 Combination module each support fractional T1/E1 on a PPP channel group in network mode. Fractional T1/E1 allows one or more DS0 channels to be bundled together (up to the maximum bandwidth of the network link), allowing the customer to use only that portion of the link that is needed. This means that the PPP service can use a selected number of timeslots (octets) in the network T1 or E1 link, thus reducing the amount of T1 or E1 bandwidth that must be leased or purchased from the attached carrier. This leads to multiplexing efficiencies in the transport network.

Only one channel group can be configured per port. When the channel group is configured for ppp-auto encapsulation and network mode, all timeslots (channels) are automatically allocated to the channel group. The user can then configure the number of timeslots needed. Timeslots not selected cannot be used.

3.1.3. Configuring Ports

A port can be configured after the IOM is activated (the card slot and card type are designated) and the adapter card slot is preprovisioned with an allowed adapter card type.

The 7705 SAR supports the port types listed below:

In addition, this section contains information on the following topics:

3.1.3.1. Ethernet

Ethernet ports are supported on the following cards, modules, and platforms:

3.1.3.1.1. 6-port Ethernet 10Gbps Adapter Card

The 6-port Ethernet 10Gbps Adapter card has four SFP ports for 1-Gb/s fiber or copper SFP transceivers and two SFP+ ports for 10-Gb/s fiber or copper SFP+ transceivers. The card also supports synchronous Ethernet timing. The 6-port Ethernet 10Gbps Adapter card is designed to complement or replace the 8-port Ethernet Adapter card or the 8-port Gigabit Ethernet Adapter card in situations where greater processing power and higher throughput capacity are required.

There are two versions of this card: 6-port Ethernet 10Gbps Adapter card and 6-port Ethernet 10Gbps Adapter card-E. The versions have identical functionality except that the 6-port Ethernet 10Gbps Adapter card-E does not have encryption functionality.

The ports and features on the 6-port Ethernet 10Gbps Adapter card are identical to the ports and features on the 8-port Gigabit Ethernet Adapter card, version 3, except that the 6-port Ethernet 10Gbps Adapter card uses only 4-priority schedulers for QoS instead of 4-priority or 16-priority schedulers.

3.1.3.1.2. 8-port Ethernet Adapter Card

The 8-port Ethernet Adapter card (the 7705 SAR-18 only supports version 2) has six RJ-45 ports for 10/100Base-T (Ethernet and Fast Ethernet) connections. The card also has two SFP ports for fiber or copper SFPs. Fast Ethernet and Gigabit (100 Mb/s and 1000 Mb/s) fiber connections and 10/100/1000Base-T copper connections are supported. This variety of connections enables the 8-port Ethernet Adapter card to be connected to different devices at the customer site, including wireless base stations, DSL modems, microwave boxes, and other auxiliary equipment. As well, with fiber connections, the adapter card can be directly connected to the Metro Ethernet Provider (MEP) central office. Version 2 of the 8-port Ethernet Adapter card also supports synchronous Ethernet timing.

3.1.3.1.3. 8-port Gigabit Ethernet Adapter Card

The 8-port Gigabit Ethernet Adapter card has eight SFP ports for fiber or copper SFPs. The card supports dual rate (100 Mb/s and 1000 Mb/s) and Gigabit (1000 Mb/s) fiber connections and 10/100/1000Base-T copper connections. The card also supports synchronous Ethernet timing. The 8-port Gigabit Ethernet Adapter card is designed to complement or replace the 8-port Ethernet Adapter card in situations where greater processing power and higher throughput capacity are required.

There are three versions of the 8-port Gigabit Ethernet Adapter card. Version 1 and version 2 are identical except that version 2 provides larger table space for FIBs, ACLs, and so on. Version 2 also supports the full IPv6 subnet range for IPv6 static routes and interface IP addresses. The static route range is from /1 to /128, and the default route is ::/0. Supported interface IP address prefixes are from /4 to /127, and /128 on system or loopback interfaces. Version 3 is identical to version 2 except that it is equipped with a hardware-based encryption engine to support features such as IPSec.

Higher limits and full subnet ranges are supported only when all the adapter cards in a particular node are equipped with hardware for larger table support.

Gigabit Ethernet optical ports offer significant advantages over fast Ethernet ports, even where lower-speed services are currently offered. With Gigabit Ethernet, service providers have the opportunity to standardize access infrastructure, ensure that capacity is available to accommodate growing bandwidth requirements, and minimize the operational costs associated with future service upgrades to hardware and software.

3.1.3.1.4. 10-port 1GigE/1-port 10GigE X-Adapter Card

There are two versions of the 10-port 1GigE/1-port 10GigE X-Adapter card. Both versions are identical except that version 2 is equipped with a hardware-based encryption engine to support features such as IPSec. The card is supported only on the 7705 SAR-18.

When the 10-port 1GigE/1-port 10GigE X-Adapter card is configured in 10-port GigE mode, 10 SFP ports are available for fiber SFP transceivers. In this mode, the card supports dual-rate (100 Mb/s and 1000 Mb/s) and Gigabit (1000 Mb/s) fiber connections. The card also supports synchronous Ethernet timing.

When the 10-port 1GigE/1-port 10GigE X-Adapter card is configured in 1-port GigE mode, only one SFP+ (port 1) of the 10 ports is active and available for use with fiber SFP+ transceivers. The card supports 10-Gb/s fiber connections. The card also supports synchronous Ethernet timing. The 1-port GigE mode is designed for use in situations where greater processing power and higher throughput capacity are required.

The 10-port 1GigE/1-port 10GigE X-Adapter card also provides larger table space for FIBs, ACLs, and so on. The card also supports the full IPv6 subnet range for IPv6 static routes and interface IP addresses. The static route range is from /1 to /128, and the default route is ::/0. Supported interface IP address prefixes are from /4 to /127, and /128 on system or loopback interfaces.

Higher limits and full subnet ranges are supported only when all the adapter cards in a particular node are equipped with hardware for larger table support.

3.1.3.1.5. 2-port 10GigE (Ethernet) Adapter Card/Module

The 2-port 10GigE (Ethernet) Adapter card/module is used to connect to and from access rings carrying a high concentration of traffic. Table 3 lists the maximum number of cards or modules that are supported on each platform. A single card can be installed in the 7705 SAR-8 and the 7705 SAR-18; however, it is strongly recommended that a minimum of two cards be installed for redundancy.

Table 3:  Maximum Number of Cards/Modules Supported in Each Chassis 

Chassis

Maximum Number of Cards or Modules

7705 SAR-8 with CSMv2

Up to four cards

7705 SAR-18

Up to six cards

7705 SAR-M

One module

The 2-port 10GigE (Ethernet) Adapter card/module has two small form-factor pluggable (XFP) ports on its faceplate. The two XFP ports are for 10-Gigabit Ethernet XFPs. The card provides high processing power and throughput capacity and operates at 10 Gb/s for Ethernet ports and 2.5 Gb/s for the virtual port (v-port).

The 2-port 10GigE (Ethernet) Adapter card provides larger table space for FIBs, ACLs, and so on. The card also supports the full IPv6 subnet range for IPv6 static routes and interface IP addresses on the v-port. The supported range for statically provisioned or dynamically learned routes is from /1 to /128. Supported interface IP address prefixes are from /4 to /127, and /128 on system or loopback interfaces.

The 2-port 10GigE (Ethernet) module supports IPv6 on the v-port. The supported range for statically provisioned or dynamically learned routes is from /1 to /64 or is /128 (indicating a host route). Supported interface IP address prefixes are from /4 to /64, and /128 on system or loopback interfaces.

The 2-port 10GigE (Ethernet) Adapter card/module supports LLDP on the Ethernet ports but not on the v-port.

3.1.3.1.6. Packet Microwave Adapter Card

The Packet Microwave Adapter card has two RJ-45 ports (ports 1 and 2) and six SFP ports (ports 3 through 8). All ports provide 10/100/1000 Mb/s connections (when connected to an MPR-e radio, they are always in Gigabit Ethernet (1-Gb/s) mode). Ports 1 through 4 support Microwave Awareness (MWA) and Ethernet/IP/MPLS networking; ports 5 through 8 support Ethernet/IP/MPLS networking only.

All Gigabit Ethernet ports provide the same networking feature capability as the 8-port Gigabit Ethernet Adapter card. For frequency synchronization, synchronous Ethernet and SSM are the mechanisms that are applied when using optical 1000Base-SX to connect to an MPR-e radio. When using electrical 1000Base-T to connect the Packet Microwave Adapter card and an MPR-e radio, Proprietary Clock Recovery (PCR) is used (a copper SFP is mandatory on ports 3 and 4).

3.1.3.1.7. 4-port SAR-H Fast Ethernet Module

The 4-port SAR-H Fast Ethernet module has four RJ-45 Fast Ethernet ports (10/100 Mb/s) on its faceplate. Any functionality supported on the 7705 SAR-H Ethernet ports is also supported on the 4-port SAR-H Fast Ethernet module, with the exception of hierarchical QoS (H-QoS) functionality and hybrid mode.

3.1.3.1.8. 6-port SAR-M Ethernet Module

The 6-port SAR-M Ethernet module has six Ethernet ports:

  1. two SFP Fast Ethernet ports (10/100 Mb/s) (ports 1 and 2)
  2. two XOR (combination) SFP/RJ point five Gigabit Ethernet ports (10/100/1000 Mb/s) (ports 3a/3b and 4a/4b)
  3. two PoE-capable RJ point five copper Gigabit Ethernet ports (10/100/1000 Mb/s) (ports 5 and 6)

Ports 5 and 6 can each support Power over Ethernet (PoE). Port 5 can also support PoE+, but if it is configured for PoE+, then port 6 cannot support PoE power.

Any functionality supported on the 7705 SAR-M Ethernet ports is also supported on the 6-port SAR-M Ethernet module, with the exception of half-duplex mode (all ports) and hybrid mode (Fast Ethernet ports only).

3.1.3.1.9. 7705 SAR-A

The 7705 SAR-A has two variants with fixed physical configurations. One variant supports both Ethernet and T1/E1 ports. The other variant supports only Ethernet ports. Both variants of the 7705 SAR-A have 12 Ethernet ports:

  1. four XOR (combination) Gigabit Ethernet ports, either 10/100/1000Base-T RJ-45 (ports 1A to 4A) or 100/1000 Mb/s SFP (ports 1B to 4B)
  2. four SFP Gigabit Ethernet ports (100/1000 Mb/s) (ports 5 to 8)
  3. four RJ-45 Fast Ethernet ports (10/100 Mb/s) (ports 9 to 12)

3.1.3.1.10. 7705 SAR-Ax

The 7705 SAR-Ax has a fixed physical configuration that has 12 Ethernet ports:

  1. four XOR (combination) Gigabit Ethernet ports, either 10/100/1000Base-T RJ-45 (ports 1A to 4A) or 100/1000 Mb/s SFP (ports 1B to 4B)
  2. eight SFP Gigabit Ethernet ports (100/1000 Mb/s) (ports 5 to 12)

3.1.3.1.11. 7705 SAR-H

The 7705 SAR-H has a fixed physical configuration that has eight Ethernet ports:

  1. two SFP Gigabit Ethernet ports (10/100/1000 Mb/s) (ports 1 and 2)
  2. two XOR (combination) RJ-45/SFP Gigabit Ethernet ports (10/100/1000 Mb/s) (ports 3 and 4)
  3. four PoE-capable RJ-45 Gigabit Ethernet ports (10/100/1000 Mb/s) (ports 5 to 8)

The 7705 SAR-H also has two module slots.

If a PoE Power Supply is connected, it increases the number of Ethernet ports that can supply PoE to a connected device.

3.1.3.1.12. 7705 SAR-Hc

The 7705 SAR-Hc has a fixed physical configuration that has six Ethernet ports:

  1. two SFP Gigabit Ethernet ports (10/100/1000 Mb/s) (ports 1 and 2)
  2. two Gigabit Ethernet RJ-45 ports (10/100/1000 Mb/s) (ports 3 and 4)
  3. two PoE-capable RJ-45 Gigabit Ethernet ports (10/100/1000 Mb/s) (ports 5 and 6)

3.1.3.1.13. 7705 SAR-M

The 7705 SAR-M has a fixed physical configuration that has four variants. All variants of the 7705 SAR-M have seven Ethernet ports:

  1. four SFP Gigabit Ethernet ports (10/100/1000 Mb/s) (ports 1 to 4)
  2. three Gigabit Ethernet RJ-45 ports (10/100/1000 Mb/s) (ports 5 to 7)

Two variants of the 7705 SAR-M also have a module slot.

3.1.3.1.14. 7705 SAR-W

The 7705 SAR-W has a fixed physical configuration that has five Ethernet ports:

  1. three SFP Gigabit Ethernet ports (10/100/1000 Mb/s) (ports 1 to 3)
  2. two PoE+ capable Gigabit Ethernet RJ-45 ports (10/100/1000 Mb/s) (ports 4 and 5)

3.1.3.1.15. 7705 SAR-Wx

The 7705 SAR-Wx has six variants with fixed physical configurations that provide the following Ethernet interfaces.

Two variants have five Gigabit Ethernet ports:

  1. three SFP Gigabit Ethernet ports (10/100/1000 Mb/s) (ports 1 to 3)
  2. two Gigabit Ethernet RJ-45 ports (10/100/1000 Mb/s) (ports 4 and 5)

Two variants have five Gigabit Ethernet ports:

  1. three SFP Gigabit Ethernet ports (10/100/1000 Mb/s) (ports 1 to 3)
  2. one Gigabit Ethernet RJ-45 port (10/100/1000 Mb/s) (port 4)
  3. one PoE+ Gigabit Ethernet RJ-45 port (10/100/1000 Mb/s) (port 5)

Two variants have four Gigabit Ethernet ports:

  1. three SFP Gigabit Ethernet ports (10/100/1000 Mb/s) (ports 1 to 3)
  2. one Gigabit Ethernet RJ-45 port (10/100/1000 Mb/s) (port 4)

3.1.3.1.16. 7705 SAR-X

The 7705 SAR-X has a fixed physical configuration that has 14 Ethernet ports:

  1. four XOR (combination) RJ-45/SFP Gigabit Ethernet ports (10/100/1000 Mb/s) (ports 2/1A, 2/2A, 3/1A, 3/2A for RJ-45 and 2/1B, 2/2B, 3/1B, 3/2B for SFP)
  2. eight SFP Gigabit Ethernet ports (10/100/1000 Mb/s) (ports 2/3 to 2/6 and 3/3 to 3/6)
  3. two SFP+ 10-Gigabit Ethernet ports (ports 2/7 and 3/7)

3.1.3.2. TDM

TDM ports are supported on the following cards, modules, and platforms:

3.1.3.2.1. 16-port T1/E1 ASAP Adapter Card

There are two versions of the 16-port T1/E1 ASAP Adapter card. The 7705 SAR-18 only supports version 2.

Channelization is supported down to the DS0 level. To change port types, all ports must first be shut down. The ports can be configured for DS1 (T1) or E1 operation. All ports on the card must be either T1 or E1; there cannot be a mix of the two types. When the first port is configured on a card, all other ports on the card must be set to the same type.

The 16-port T1/E1 ASAP Adapter card supports fractional T1/E1 on network ports configured for PPP. Fractional T1/E1 allows a portion of the link to be used for traffic (up to the full link bandwidth).

DS1 ports on the 16-port T1/E1 ASAP Adapter card, version 2, can be configured for either B8ZS (bipolar with eight-zero substitution) zero code suppression or AMI (alternate mark inversion). B8ZS and AMI are line coding techniques.

3.1.3.2.2. 32-port T1/E1 ASAP Adapter Card

On the 32-port T1/E1 ASAP Adapter card, channelization is supported down to the DS0 level. To change port types, all ports must first be shut down. The ports can be configured for DS1 (T1) or E1 operation. All ports on the card must be either T1 or E1; there cannot be a mix of the two types. When the first port is configured on a card, all other ports on the card must be set to the same type.

The 32-port T1/E1 ASAP Adapter card supports fractional T1/E1 on network ports configured for PPP. Fractional T1/E1 allows a portion of the link to be used for traffic (up to the full link bandwidth).

DS1 ports on the card can be configured for either B8ZS (bipolar with eight-zero substitution) zero code suppression or AMI (alternate mark inversion). B8ZS and AMI are line coding techniques.

3.1.3.2.3. 2-port OC3/STM1 Channelized Adapter Card

On the 2-port OC3/STM1 Channelized Adapter card, channelization is supported down to the DS0 level. To change port types, all ports must first be shut down. The ports can be configured for DS1 (T1) or E1 channelization. All ports on the card must be either SONET or SDH; there cannot be a mix of the two types. When the first port is configured on a card, all other ports on the card must be set to the same type.

The 2-port OC3/STM1 Channelized Adapter card also supports DS3 channelization on access for TDM services as well as network mode with PPP.

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

The 4-port OC3/STM1 / 1-port OC12/STM4 Adapter card can be configured to be in 4-port OC3/STM1 mode or 1-port OC12/STM4 mode (using the mda-mode command).

When the 4-port OC3/STM1 / 1-port OC12/STM4 Adapter card is configured in 4-port OC3/STM1 mode, four SFP ports are available for optical and electrical SFP transceivers. In this mode, the card supports OC3 SONET or STM1 SDH transmission.

When the 4-port OC3/STM1 / 1-port OC12/STM4 Adapter card is configured in 4-port OC3/STM1 mode, channelization is supported down to the DS1 level. To change port types, all ports must first be shut down. The ports can be configured for DS1 (T1) or E1 channelization in access mode, or PPP/MLPPP or POS in network mode. All ports on the card must be either SONET or SDH; there cannot be a mix of the two types. When the first port is configured on a card, all other ports on the card must be set to the same type. Switching between port types causes the adapter card to reset.

When the 4-port OC3/STM1 / 1-port OC12/STM4 Adapter card is configured in 1-port OC12/STM4 mode, SFP port 1 is available for optical SFP transceivers. Ports 2 through 4 are not available. In this mode, the card supports OC12 SONET and STM4 SDH transmission. The 1-port OC12/STM4 mode is designed for use in situations where greater bandwidth is required on a single port.

3.1.3.2.5. 4-port DS3/E3 Adapter Card

The 4-port DS3/E3 Adapter card has four TDM DS3/E3 ports. The port type must be configured to be either DS3 or E3. Each DS3 port can be clear channel or channelized down to DS0 (64 kb/s). E3 ports can be clear channel only. Once the first port type has been configured, all other ports on the same 4-port DS3/E3 Adapter card must be set to the same type.

To change between types, the ports must first be deleted. DS3 ports provide B3ZS (bipolar with three-zero substitution) zero code suppression and E3 ports provide HDB3 (high density bipolar of order 3) zero code suppression. B3ZS and HDB3 zero code suppression are line coding techniques.

Channelization is supported down to the DS0 level (for DS3 ports only). To change port types, all ports must first be shut down. The ports can be configured for DS1 (T1) or E1 operation. All ports on the card must be either T1 or E1; there cannot be a mix of the two types. When the first port is configured on a card, all other ports on the card must be set to the same type.

3.1.3.2.6. 8-port Voice & Teleprotection Card

On the 8-port Voice & Teleprotection card, channelization is supported down to the DS0 level. To change port types, all ports must first be shut down. The ports can be configured for DS1 (T1) or E1 operation. All ports on the card must be either T1 or E1; there cannot be a mix of the two types. When the first port is configured on a card, all other ports on the card must be set to the same type.

Channelization is supported on the two codirectional G.703 ports and two IEEE C37.94 teleprotection interface ports.

3.1.3.2.7. 8-port C37.94 Teleprotection Card

On the 8-port C37.94 Teleprotection card, channelization is supported down to the DS0 level on the eight IEEE C37.94 teleprotection interface (TPIF) ports.

3.1.3.2.8. 12-port Serial Data Interface Card

The 12-port Serial Data Interface card, version 1 and version 2, has four connectors, which support three serial data ports each. Each port grouping can be configured for V.35, RS-232, or X.21 operation. When a port has been configured for a specific interface type, the other two ports in that same grouping must be configured for the same type. The card also supports an RS-530 interface with the use of an adapter cable that connects to a DB15 connector on the front of the X.21 distribution panel. There is no configuration specifically for the RS-530 interface; configuration is done in X.21 mode and applies to the RS-530 interface when it is physically enabled through hardware. All X.21 functionality is available on the RS-530 interface, except that only DCE operation is supported for RS-530. However, because X.21 does not support all the control leads available for RS-530, only a subset of the RS-530 control leads are supported.

The 12-port Serial Data Interface card, version 3, has six connectors, which support two data ports each. Each port grouping can be configured for V.35, RS-232, X.21, or RS-530 operation. When a port has been configured for a specific interface type, the other port in the group must be configured for the same type.

Channelization on the 12-port Serial Data Interface card is supported down to the DS0 level.

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

T1/E1 ports on the 4-port T1/E1 and RS-232 Combination module (supported on the 7705 SAR-H) support channelization down to the DS0 level. To change port types, all ports must first be shut down. The ports can be configured for DS1 (T1) or E1 operation. All ports on the module must be either T1 or E1; there cannot be a mix of the two types. When the first port is configured on a module, all other ports on the card must be set to the same type.

3.1.3.2.10. 7705 SAR-A

The 7705 SAR-A has two variants with fixed physical configurations. One variant supports both Ethernet and T1/E1 ports. The other variant supports only Ethernet ports. The variant that supports T1/E1 ports includes eight RJ-45 T1/E1 ports. All ports must be configured as either T1 or E1 ports; a mix of T1 and E1 ports is not allowed.

DS1 (T1) ports on the chassis can be configured for either B8ZS (bipolar with eight-zero substitution) zero code suppression or AMI (alternate mark inversion). B8ZS and AMI are line coding techniques.

3.1.3.2.11. 7705 SAR-Hc

The 7705 SAR-Hc has a fixed physical configuration that includes two RS-232 RJ-45 ports. The chassis also includes Gigabit Ethernet/Ethernet support via SFP and RJ-45 ports.

3.1.3.2.12. 7705 SAR-M

The 7705 SAR-M has a fixed physical configuration that has four variants. Two variants have 16 RJ-45 T1/E1 ports. All ports must be configured as either T1 or E1 ports; a mix of T1 and E1 ports is not allowed.

DS1 (T1) ports on the chassis can be configured for either B8ZS (bipolar with eight-zero substitution) zero code suppression or AMI (alternate mark inversion). B8ZS and AMI are line coding techniques.

3.1.3.2.13. 7705 SAR-X

The 7705 SAR-X has a fixed physical configuration that provides TDM pseudowire services via eight T1/E1 RJ-45 ports.

3.1.3.3. DSL

The 6-port DSL Combination module and the 8-port xDSL module (supported on the 7705 SAR-M), and two variants of the 7705 SAR-Wx support DSL.

The 6-port DSL Combination module has six RJ-11 ports on its faceplate. Four of the RJ-11 ports support G.SHDSL.bis pairs, and two RJ-11 ports support xDSL operating in ADSL2,ADSL2+, or VDSL2 mode with no intermixing of DSL types.

The 8-port xDSL module has eight RJ-11 ports on its faceplate that support ADSL2, ADSL2+, or VDSL2 mode with no intermixing of DSL types.

The 7705 SAR-M views the Ethernet link on a DSL module as an Ethernet port. Any services on the 7705 SAR that are supported on an Ethernet port are also supported on the Ethernet link on a DSL module.

Two variants of the 7705 SAR-Wx support one 4-pair xDSL port.

3.1.3.4. GNSS Receiver

The 7705 SAR-H GPS Receiver module is equipped with a GPS RF port for retrieval and recovery of GPS and GLONASS signals. The 7705 SAR-Ax and some variants of the 7705 SAR-Wx are equipped with an integrated GNSS receiver and a GNSS RF port for retrieval and recovery of GPS and GLONASS signals.

The GNSS Receiver card installed in the 7705 SAR-8 or 7705 SAR-18 is equipped with a GNSS RF port for retrieval and recovery of both GPS and GLONASS signals.

Note:

GLONASS-only signal recovery is not supported in this release.

3.1.3.5. GPON

The GPON module is a single-port optical network terminal (ONT) that integrates passive optical network (PON) capabilities into the 7705 SAR-M. The GPON module serves as an Ethernet Layer 2 connection point for receiving data from and transmitting data into a GPON network.

The GPON module connects to the 7705 SAR-M as a Gigabit Ethernet port. From an operational perspective, the 7705 SAR-M views the module as one of its Ethernet ports.

3.1.3.6. Multilink Bundles

A multilink bundle is a collection of channels on channelized ports that physically reside on the same adapter card. Multilink bundles are used by providers who offer either bandwidth-on-demand services or fractional bandwidth (DS3) services. Multilink bundles are supported over PPP channels (MLPPP). All member links of an MLPPP group must be of the same type (either E1 or DS1).

The following cards, modules, and platforms support multilink bundles:

  1. T1/E1 ports on the 7705 SAR-A (variants with T1/E1 ports)
  2. T1/E1 ports on the 7705 SAR-M (variants with T1/E1 ports)
  3. T1/E1 ports on the 7705 SAR-X
    The following must have all member links of an MLPPP bundle configured on the same card or module:
    1. 16-port T1/E1 ASAP Adapter card
    2. 32-port T1/E1 ASAP Adapter card
    3. T1/E1 ports on the 4-port T1/E1 and RS-232 Combination module (on 7705 SAR-H)
    The following must have all member links of an MLPPP bundle configured on the same card or module, and on the same port:
    1. 2-port OC3/STM1 Channelized Adapter card
    2. 4-port OC3/STM1 / 1-port OC12/STM4 Adapter card

3.1.3.7. IMA

The 16-port T1/E1 ASAP Adapter card, 32-port T1/E1 ASAP Adapter card, and the 2-port OC3/STM1 Channelized Adapter card support Inverse Multiplexing over ATM (IMA). IMA is a standard developed to address the increasing need for bandwidth greater than the DS1 or E1 link speeds (1.544 or 2.048 Mb/s, respectively) but less than higher link speeds such as DS3 (44.736 Mb/s). IMA combines the transport bandwidth of multiple DS1 or E1 channels in a logical link (called an IMA group) to provide scalable bandwidth.

3.1.3.8. SONET/SDH

The 4-port OC3/STM1 Clear Channel Adapter card has four hot-pluggable, SFP-based ports that can be independently configured to be SONET (OC3) or SDH (STM1).

The 2-port OC3/STM1 Channelized Adapter card has two hot-pluggable, SFP-based ports that can be configured to be SONET (OC3) or SDH (STM1). All ports on the 2-port OC3/STM1 Channelized Adapter card must be of the same type (either SONET or SDH).

The 4-port OC3/STM1 / 1-port OC12/STM4 Adapter card has four hot-pluggable, SFP-based ports that can be configured to be SONET (OC3 or OC12) or SDH (STM1 or STM4). The card can be configured to be in either 4-port mode or 1-port mode (using the mda-mode command). In 4-port mode, all four ports can be configured as OC3 or STM1. In 1-port mode, only port 1 can be configured as OC12 or STM4. All ports on the 4-port OC3/STM1 / 1-port OC12/STM4 Adapter card must be of the same type (either SONET or SDH).

3.1.3.9. Voice

Voice ports are supported on the following cards:

3.1.3.9.1. 6-port E&M Adapter Card

The 6-port E&M Adapter card has six RJ-45 ports that support the transport of an analog voiceband signal between two analog devices over a digital network. The analog signals are converted into a 64 kb/s digital Pulse Code Modulation (PCM) format using either Mu-Law (North America) or A-Law (Rest of World) companding. The type of companding is selectable on a per-card basis. Companding conversion (that is, Mu-Law to A-Law or vice versa) is not supported.

The signaling type is selectable on a per-card basis. When either A-Law or Mu-Law companding is configured, Type I, Type II, or Type V signaling can be selected. However, the only supported configurations are both ends of the connection operating in the same mode (for example, Type I to Type I) or one end operating in Type I mode and the other in Type V mode. The default signaling type for Mu-Law is Type I and the default signaling type for A-Law is Type V.

Each voice port can be configured to operate in either a two-wire or four-wire (default) mode. The ports (in groups of three – ports 1 to 3 and ports 4 to 6) can also be configured to operate in transmission-only mode, which provides a four-wire audio path with no signaling. A transmit and receive transmission level point (the analog-to-digital decibel level) can be configured for each port. See Table 4 for the signaling type, companding law, and audio wires configuration options on the 6-port E&M Adapter card.

Table 4:  Configuration Options for the 6-port E&M Adapter Card 

Signaling Type

Companding Type

Number of Wires

Type I, Type II, Type V

Mu-Law or A-Law

Two-wire or four-wire

Transmission-only (no signaling)

Mu-Law or A-Law

Four-wire

3.1.3.9.2. 8-port Voice & Teleprotection Card

The 8-port Voice & Teleprotection card supports the transport of an analog voiceband signal between two analog devices over a digital network.

The card has two FXS RJ-45 ports and two FXO RJ-45 ports that support analog voiceband signals. The analog signals are converted into a 64 kb/s digital Pulse Code Modulation (PCM) format using either Mu-Law (North America) or A-Law (Rest of World) companding. The type of companding is selectable on a per-card basis. Companding conversion (that is, Mu-Law to A-Law or vice versa) is not supported.

The signaling type is selectable at the port level on a per-port basis depending on companding type.

FXO supports:

  1. 1511profile1 (1511 Loop Start) – A-Law companding
  2. 3600ls (Loop Start) – Mu-Law companding
  3. 3600re (Remote Extension) – A-Law companding
  4. 1511sn137 (1511 profile 137) – A-Law companding

FXS supports:

  1. 3600plar (Private Line Automatic Ringdown) – A-Law and Mu-Law companding
  2. 1511plar – A-Law companding
  3. 1511profile1 (Loop Start) – A-Law companding
  4. 3600ls (Loop Start) – Mu-Law companding
  5. 3600re (Remote Extension) – A-Law companding
  6. 1511sn137 (1511 profile 137) – A-Law companding

The default signaling type for FXO and FXS is 3600ls for Mu-Law companding and 3600re for A-Law companding.

3.1.3.9.3. 8-port FXO Adapter Card

The 8-port FXO Adapter card supports the transport of an analog voiceband signal between two analog devices over a digital network.

The card supports analog voiceband signals through four RJ-45 connectors that provide eight Foreign Exchange Office (FXO) ports, with two ports supported per connector. The analog signals are converted into a 64 kb/s digital Pulse Code Modulation (PCM) format using either Mu-Law (North America) or A-Law (Rest of World) companding. The type of companding is selectable on a per-card basis. Companding conversion (that is, Mu-Law to A-Law or vice versa) is not supported.

The signaling type is selectable at the port level on a per-port basis depending on companding type.

FXO supports:

  1. 1511profile1 (1511 loop start) – A-Law companding
  2. 3600ls (loop start) – Mu-Law companding
  3. 3600re (remote extension) – A-Law companding
  4. 1511sn137 (1511 profile 137) – A-Law companding

The default signaling type is 3600ls for Mu-Law companding and 3600re for A-Law companding.

3.1.3.9.4. 6-port FXS Adapter Card

The 6-port FXS Adapter card provides the capability of transporting a large number of voice circuits from one 7705 SAR location and terminating them at another 7705 SAR location that is connected to a PBX.

The card can also be configured for a Private Line Automatic Ringdown (PLAR) application, which is typically used outside of a PBX network, in order to provide a site-to-site or remote site-to-control center hotline functionality.

The card has six Foreign Exchange Subscriber (FXS) ports. Each port provides a short-reach, on-premises analog interface to an analog telephone set. After an incoming analog signal from a set is terminated on one of the FXS interfaces, it is converted into a digital 64 kb/s Pulse Code Modulation (PCM) format using either Mu-Law companding (North America) or A-Law companding (Rest of World).

The signal is then mapped into the E1 Channel Associated Signaling (CAS) transport scheme for A-Law or the T1 Robbed Bit Signaling (RBS) transport scheme for Mu-Law and transmitted using a Cpipe over any 7705 SAR network interface that supports the Cpipe service. For standard TDM, the network interface can be a T1/E1 or OC3/STM1 channelized interface. For MPLS, an Ethernet, T1/E1, OC3/STM1 channelized MLPPP, or OC3/STM1 clear channel interface can be used.

For a PBX application, the signal is terminated at the 7705 SAR hub location that is connected to a PBX by either an FXO interface or a T1/E1 interface (assuming the signaling formats are compatible). The FXO interface can be provided by either an 8-port FXO Adapter card or 8-port Voice & Teleprotection card that is installed in a 7705 SAR-8 or 7705 SAR-18 chassis at the 7705 SAR hub location.

For a PLAR application, the signal is terminated on an FXS interface on either another 6-port FXS Adapter card or an 8-port Voice & Teleprotection card that is installed in a 7705 SAR-8 or 7705 SAR-18 chassis that is located at a remote location, or terminated on a 3600 MainStreet or 1511 MAX. The connection is made over an E1 interface ⌠(3600 MainStreet or 1511 MAX) or a T1 interface (3600 MainStreet). A hotline call can originate from a 3600 MainStreet or 1511 MAX and terminate on an FXS interface on a 6-port FXS Adapter card (or on an FXS interface on an 8-port Voice & Teleprotection card).

Table 5 shows the configuration options available on a 6-port FXS Adapter card. The companding law type is configured at the card level; the other options are configured at the voice port level.

Table 5:  Configuration Options for the 6-port FXS Adapter Card 

Configuration

Supported Options

Companding type

Mu-Law (the default)

A-Law

Fault signaling

Idle (the default)

Seized

Line balance

Nominal (the default)

800

Ring generation

16 Hz (the default)

20 Hz

25 Hz

Signaling type

3600 Private Line Automatic Ringdown (PLAR) (if Mu-Law or A-Law is used)

1511 PLAR (if A-Law is used)

1511 Profile1 (if A-Law is used)

3600 Loop Start (LS) (if Mu-Law is used; this is the default)

3600 Remote Extension (RE) (if A-Law is used; this is the default)

1511sn137 (1511 profile 137) (if A-Law is used)

Transmission level point (TLP)

Rx: –7 dB to 0 dB (1-dB increments; the default is –3 dB)

Tx: –4 dB to +3 dB (1-dB increments; the default is 0 dB)

3.1.3.10. Microwave Link

A microwave link can be configured as a virtual port object on a 7705 SAR-8 or 7705 SAR-18 in order to provide a basic microwave connection or the Microwave Awareness (MWA) capability to an MPR-e node.

For more information, see Microwave Link.

3.1.3.11. CLI Identifiers for Adapter Cards, Modules and Platforms

On the CLI, the adapter cards are referred to as MDAs. A port is identified using the format slot/mda/port, where slot identifies the IOM card slot ID (always 1), mda identifies the physical slot in the chassis for the adapter card, and port identifies the physical port on the adapter card; for example, 1/5/1. Adapter cards are configured at the card and port level.

On the fixed platforms, no configuration is required at the adapter card level in order to provision the ports.

On the CLI for the 7705 SAR-A, the slot/mda identifier for T1/E1 ports is 1/2 and for Ethernet ports is 1/1. T1/E1 ports are identified as 1/2/1 through 1/2/8 for the variant of the chassis with T1/E1 ports. Ethernet ports for both variants of the 7705 SAR-A are identified as 1/1/1 through 1/1/12.

On the CLI for the 7705 SAR-Ax, the slot/mda identifier for Ethernet ports is 1/1 and for the GNSS RF port is 1/2.

On the CLI for the 7705 SAR-H, the slot/mda identifier for Ethernet ports is 1/1. The chassis has two slots for modules (the 4-port T1/E1 and RS-232 Combination module, the GPS Receiver module, and the 4-port SAR-H Fast Ethernet module). On the CLI, the slot/mda identifier for a module installed in the first slot position is 1/2 and for a module installed in the second slot position is 1/3. Ethernet ports are identified as 1/1/1 through 1/1/8. Module ports are identified as 1/2/port-num for modules installed in the first slot position and 1/3/port-num for modules installed in the second slot position.

On the CLI for the 7705 SAR-Hc, the slot/mda identifier for Ethernet ports is 1/1 and for RS-232 ports is 1/2. Ethernet ports are identified as 1/1/1 through 1/1/6 and RS-232 ports are identified as 1/2/1 and 1/2/2.

On the CLI for the 7705 SAR-M, the slot/mda identifier for T1/E1 ports is 1/2 and for Ethernet ports is 1/1. For those variants of the chassis that have a module slot, the slot/mda identifier for the module on the CLI is 1/3. The 7705 SAR-M variants with module slots support the following modules: GPON module, 6-port DSL Combination module, 8-port xDSL module, CWDM OADM module, 2-port 10GigE (Ethernet) module, and 6-port SAR-M Ethernet module. T1/E1 ports are identified as 1/2/1 through 1/2/16 for those variants of the chassis with T1/E1 ports. Ethernet ports for all variants of the 7705 SAR-M are identified as 1/1/1 through 1/1/7. Those variants of the chassis that have module slots identify module ports as 1/3/port-num.

On the CLI for the 7705 SAR-W, the slot/mda identifier for the Ethernet ports is 1/1. Ethernet ports are identified as 1/1/1 through 1/1/5. The 7705 SAR-W also has an internal (virtual) port used for in-band Ethernet management connection. The virtual port is identified as vrtl-mgmt on the CLI and as 1/1/6 via SNMP.

On the CLI for the 7705 SAR-Wx, the slot/mda identifier for the Ethernet ports is 1/1 and 1/2 for the xDSL port. Ethernet ports for the Ethernet-only variant and the Ethernet and PoE+ variant are identified as 1/1/1 through 1/1/5. For the variant supporting Ethernet ports and an xDSL port, the Ethernet ports are identified as 1/1/1 through 1/1/4 and the DSL port is identified as 1/2/1 through 1/2/4.

On the CLI for the 7705 SAR-X, the slot/mda identifier is specified as 1 for T1/E1 ports and 2 or 3 for Ethernet ports. The port number is specified as a variable that can have a value from 1 to 8 for T1/E1 ports or 1 to 7 for Ethernet ports, depending on how the port is configured.

For the 16-port T1/E1 ASAP Adapter card, 32-port T1/E1 ASAP Adapter card, and 4-port DS3/E3 Adapter card, the channel-group-id identifies the DS1 or E1 channel group; for example, 1/5/1.20. For the 2-port OC3/STM1 Channelized Adapter card, the channel-group-id identifies the DS1, E1, or DS3 channel group. For the 4-port OC3/STM1 / 1-port OC12/STM4 Adapter card, the channel-group-id identifies the DS1 or E1 channel group. For the 12-port Serial Data Interface card, the channel-group-id identifies the V.35, RS-530, RS-232, or X.21 channel group; only one channel group per port is supported on the card, so the format would be 1/1/1.1.

For the 6-port E&M Adapter card, the channel-group-id identifies the E&M voice channel group; only one channel group per port is supported on the card, so the format would be 1/1/1.1. For the 8-port Voice & Teleprotection card, the 8-port C37.94 Teleprotection card, the 8-port FXO Adapter card, and the 6-port FXS Adapter card, the channel-group-id identifies the DS0 channel group; only one channel group per port is supported on the card, so the format would be 1/1/1.1.

For the 4-port T1/E1 and RS-232 Combination module, the channel-group-id identifies the DS1 or E1 channel group for the T1/E1 ports (for example, 1/2/3.5) or the channel group for the RS-232 ports (for example, 1/2/2.1).

On the CLI for the 2-port 10GigE (Ethernet) Adapter card or 2-port 10GigE (Ethernet) module, for virtual-port configuration, an Ethernet port is identified as v-port.

The following output examples display the administrative and operational states of adapter cards for all platforms.

For the 7705 SAR-8 with a CSMv2:

ALU-1>show card state 
==============================================================================
Card State
==============================================================================
Slot/  Provisioned Type                 Admin Operational   Num   Num Comments
Id         Equipped Type (if different) State State         Ports MDA
------------------------------------------------------------------------------
1      iom-sar                          up    up                  6
1/1    a12-sdiv2                        up    provisioned   12
1/2    a4-oc3                           up    provisioned   4
1/3    a16-chds1                        up    provisioned   16
1/4    a4-chds3                         up    provisioned   4
1/5    a8-eth                           up    provisioned   8
1/6    a2-choc3                         up    provisioned   2
A      csmv2-10g                        up    up                      Active
B      csmv2-10g                        up    down                    Standby
==============================================================================
ALU-1># 

For the 7705 SAR-18:

*A:ALU-1# show card state 
 
==============================================================================
Card State
==============================================================================
Slot/  Provisioned Type                 Admin Operational   Num   Num Comments
Id         Equipped Type (if different) State State         Ports MDA
------------------------------------------------------------------------------
1      iom-sar                          up    up                  12
1/1    aux-alarm                        up    up
1/2    a8-ethv2                         up    up            8
1/3    a8-ethv2                         up    up            8
1/4    a8-ethv2                         up    provisioned   8
1/5    a8-ethv2                         up    provisioned   8
1/6    a32-chds1v2                      up    up            32
1/7    a32-chds1v2                      up    up            32
1/8    a8-pmc                           up    up            8
1/9    mw-pic-2                         up    up            2
1/10   a4-oc3                           up    provisioned   4
1/11   a4-chds3                         up    provisioned   4
1/12   a2-choc3                         up    provisioned   2
1/X1   x-10GigE                         up    provisioned   1
1/X2   x-10GigE                         up    provisioned   1
1/X3   x-10GigE                         up    provisioned   1
1/X4   x-10GigE                         up    provisioned   1
A      csm-10g                          up    up                      Active
B      csm-10g                          up    down                    Standby
==============================================================================
*A:ALU-1# 

For the 7705 SAR-A:

*A:ALU-1# show card state
==============================================================================
Card State
==============================================================================
Slot/  Provisioned Type                 Admin Operational   Num   Num Comments
Id         Equipped Type (if different) State State         Ports MDA
------------------------------------------------------------------------------
1      iom-sar                          up    up                  2
1/1    i12-eth-xor                      up    up            12
1/2    i8-chds1                         up    up            8
A      csm-2.5g                         up    up                      Active
==============================================================================
*A:ALU-1#

For the 7705 SAR-Ax:

*A:sar-Ax# show card state
===============================================================================
Card State
===============================================================================
Slot/  Provisioned Type                  Admin Operational   Num   Num Comments
Id         Equipped Type (if different)  State State         Ports MDA
-------------------------------------------------------------------------------
1      iom-sar                           up    up                  2
1/1    i12-1gb-xor                       up    up            12
1/2    i1-gnss                           up    up            1
A      csm-2.5g                          up    up                      Active
===============================================================================

For the 7705 SAR-H:

*A:ALU-1# show card state
 
==============================================================================
Card State
==============================================================================
Slot/  Provisioned Type                 Admin Operational   Num   Num Comments
Id         Equipped Type (if different) State State         Ports MDA
------------------------------------------------------------------------------
1      iom-sar                          up    up                  3          
1/1    i8-1gb                           up    up           8
1/2    p4-combo                         up    up           4                 
1/3    p4-combo                         up    up           4               
A      csm-2.5g                         up    up                      Active
==============================================================================
*A:ALU-1#

For the 7705 SAR-Hc:

*A:ALU-1# show card state
 
==============================================================================
Card State
==============================================================================
Slot/  Provisioned Type                 Admin Operational   Num   Num Comments
Id         Equipped Type (if different) State State         Ports MDA
------------------------------------------------------------------------------
1      iom-sar                          up    up                  2          
1/1    i6-1gb                           up    up           6
1/2    i2-sdi                           up    up           2                 
A      csm-2.5g                         up    up                      Active
==============================================================================
*A:ALU-1#

For the 7705 SAR-M:

*A:ALU-1# show card state
 
==============================================================================
Card State
==============================================================================
Slot/  Provisioned Type                 Admin Operational   Num   Num Comments
Id         Equipped Type (if different) State State         Ports MDA
------------------------------------------------------------------------------
1      iom-sar                          up    up                  3          
1/1    i7-1gb                           up    up           7
1/2    i16-chds1                        up    up           16                 
1/3    p1-GPON                          up    up                           
A      csm-2.5g                         up    up                      Active
==============================================================================
*A:ALU-1#

For the 7705 SAR-W:

*A:ALU-1# show card state
==============================================================================
Card State
==============================================================================
Slot/  Provisioned Type                 Admin Operational   Num   Num Comments
Id         Equipped Type (if different) State State         Ports MDA
------------------------------------------------------------------------------
1      iom-sar                          up    up                  1
1/1    i5-1gb                           up    up            6
A      csm-2.5g                         up    up                      Active
==============================================================================
*A:ALU-1#

For the 7705 SAR-Wx Ethernet variant:

*A:ALU-1# show card state
==============================================================================
Card State
==============================================================================
Slot/  Provisioned Type                 Admin Operational   Num   Num Comments
Id         Equipped Type (if different) State State         Ports MDA
------------------------------------------------------------------------------
1      iom-sar                          up    up                  1
1/1    i5-1gb-b                         up    up            5
A      csm-2.5g                         up    up                      Active
==============================================================================
*A:ALU-1#

For the 7705 SAR-Wx Ethernet with xDSL variant:

*A:ALU-1# show card state
==============================================================================
Card State
==============================================================================
Slot/  Provisioned Type                 Admin Operational   Num   Num Comments
Id         Equipped Type (if different) State State         Ports MDA
------------------------------------------------------------------------------
1      iom-sar                          up    up                  2
1/1    i4-1gb-b                         up    up            4
1/2    i4-xdsl                          up    up            1
A      csm-2.5g                         up    up                      Active
==============================================================================
*A:ALU-1#

For the 7705 SAR-X:

*A:ALU-1# show card state
==============================================================================
Card State
==============================================================================
Slot/  Provisioned Type                 Admin Operational   Num   Num Comments
Id         Equipped Type (if different) State State         Ports MDA
------------------------------------------------------------------------------
1      iom-sar                           up    up                  3
1/1    i8-chds1-x                        up    up            8
1/2    i7-mix-eth                        up    up            7
1/3    i7-mix-eth                        up    up            7
A      csm-2.5g                          up    up                      Active
===============================================================================
*A:ALU-1#

3.1.3.12. Access, Network, and Hybrid Ports

All ports must be set to access (customer-facing), network, or hybrid mode. When the mode is configured on a port, the appropriate encapsulation type must be configured to distinguish the services on the port or channel (for access mode), or to define the transport mode (for network mode).

For the 16-port T1/E1 ASAP Adapter card, version 2, 32-port T1/E1 ASAP Adapter card, and 4-port DS3/E3 Adapter card, the card must be enabled to support a set of software services before the encapsulation type is configured. This support is enabled using the mda-mode command (see the mda-mode command in the Configuration Command Reference section):

  1. access ports — configured for customer-facing traffic on which services are configured. If a Service Access Point (SAP) is to be configured on the port or channel, the port or channel must be configured as an access port or channel.
    On the 16-port T1/E1 ASAP Adapter card, version 1, the encapsulation type can be ipcp, cem, or atm. The encapsulation type on the 16-port T1/E1 ASAP Adapter card, version 2, and the 32-port T1/E1 ASAP Adapter card can be ipcp, cem, atm, frame-relay, hdlc, or cisco-hdlc.
    On the 12-port Serial Data Interface card, the encapsulation type can be cem, ipcp, frame-relay, hdlc, or cisco-hdlc, depending on the interface type. V.35 ports and X.21 ports at super-rate speeds (64 kb/s and above) support all of the above encapsulation types. RS-232 ports and X.21 ports operating at subrate speeds support only cem encapsulation. RS-530 ports support only cem encapsulation.
    On the 4-port T1/E1 and RS-232 Combination module, the encapsulation type for T1/E1 ports can be ipcp or cem. RS-232 ports operating at subrate speeds support only cem encapsulation.
    On the 6-port E&M Adapter card, 8-port Voice & Teleprotection card, 8-port C37.94 Teleprotection card, 8-port FXO Adapter card, and 6-port FXS Adapter card, the encapsulation type must be cem.
    On the 8-port Ethernet Adapter card, the 8-port Gigabit Ethernet Adapter card, the 6-port Ethernet 10Gbps Adapter card, the 10-port 1GigE/1-port 10GigE X-Adapter card, the Packet Microwave Adapter card, the 4-port SAR-H Fast Ethernet module, the 6-port SAR-M Ethernet module, the xDSL ports on the 7705 SAR-Wx, and the Ethernet ports on all fixed platforms with Ethernet ports, the encapsulation type can be set as null, dot1q, or qinq.
    Note:

    1. The 10-port 1GigE/1-port 10GigE X-Adapter card supports qinq only when it is in 10-port 1GigE mode.
    2. The Packet Microwave Adapter card supports qinq only when the port is not in mw-link mode.
    On the 4-port OC3/STM1 Clear Channel Adapter card, the encapsulation type must be atm.
    On the 4-port DS3/E3 Adapter card, the encapsulation type for DS3/E3 clear channel ports can be atm, cem, or frame-relay. The encapsulation type for DS3 channelized ports can be cem or frame-relay.
    On the 2-port OC3/STM1 Channelized Adapter card, the encapsulation type can be ipcp, cem, or atm.
    On the 4-port OC3/STM1 / 1-port OC12/STM4 Adapter card, the encapsulation type must be cem.
  2. network ports — configured for network-facing traffic. Network ports are used as uplinks for Ethernet, ATM, PPP, and TDM pseudowires.
    On the Ethernet cards, the Packet Microwave Adapter card, the 2-port 10GigE (Ethernet) Adapter card, and 2-port 10GigE (Ethernet) module, the encapsulation type can be set as null or dot1q.
    Note:

    QinQ encapsulation is not supported on a port in network mode.

    The encapsulation type must be ppp-auto for PPP/MLPPP bundles on the following:
    1. T1/E1 ports on the 7705 SAR-A (variants with T1/E1 ports)
    2. T1/E1 ports on the 7705 SAR-M (variants with T1/E1 ports)
    3. T1/E1 ports on the 7705 SAR-X
    4. 16-port T1/E1 ASAP Adapter card
    5. 32-port T1/E1 ASAP Adapter card
    6. 2-port OC3/STM1 Channelized Adapter card
    7. 4-port OC3/STM1 / 1-port OC12/STM4 Adapter card
    8. T1/E1 ports on the 4-port T1/E1 and RS-232 Combination module (on 7705 SAR-H)
    Network PPP (encapsulation type ppp-auto) can be configured to use some with fractional ppp or all the timeslots on T1/E1 ports on the following cards:
    1. T1/E1 ports on the 7705 SAR-A (variants with T1/E1 ports)
    2. T1/E1 ports on the 7705 SAR-M (variants with T1/E1 ports)
    3. T1/E1 ports on the 7705 SAR-X
    4. 16-port T1/E1 ASAP Adapter card
    5. 32-port T1/E1 ASAP Adapter card
    6. T1/E1 ports on the 4-port T1/E1 and RS-232 Combination module (on 7705 SAR-H)
    On the 4-port OC3/STM1 Clear Channel Adapter card, 4-port OC3/STM1 / 1-port OC12/STM4 Adapter card, 4-port DS3/E3 Adapter card, and 2-port OC3/STM1 Channelized Adapter card, the encapsulation type must be ppp-auto. Fractional PPP is not supported on these cards; all timeslots of the DS1 channel will be used.
  3. hybrid ports — configured for access (customer-facing) and network-facing traffic. Hybrid ports can support access and network modes simultaneously over different VLANs. Within the span of a port, some of the VLANs can be in access mode and associated with SAPs for various services, while other VLANs can be in network mode and support any of the network-side operations, including label switching, IP forwarding (GRT IP routing), GRE SDPs, and so on.

The default modes are listed in Table 6. All channel groups on a port must either be all access or all network channel groups; there cannot be a mix. When the first channel group is configured, all other channel groups on that port must be set to the same mode. To change modes, all channel groups must first be shut down.

Table 6:  Default Port Mode per Adapter Card, Module, or Platform 

Default Mode

Adapter Card, Module, or Platform

Network

2-port 10GigE (Ethernet) Adapter card

2-port 10GigE (Ethernet) module

6-port DSL Combination module

8-port xDSL module

10-port 1GigE/1-port 10GigE X-Adapter card (in 1-port 10GigE mode, the port operates in network mode only)

GPON module

Access

2-port OC3/STM1 Channelized Adapter card

4-port DS3/E3 Adapter card

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

4-port OC3/STM1 Clear Channel Adapter card

4-port SAR-H Fast Ethernet module

4-port T1/E1 and RS-232 Combination module is access for the T1/E1 ports; the RS-232 ports operate in access mode only

6-port E&M Adapter card

6-port Ethernet 10Gbps Adapter card

6-port FXS Adapter card

6-port SAR-M Ethernet module

8-port Ethernet Adapter card

8-port FXO Adapter card

8-port Gigabit Ethernet Adapter card

8-port Voice & Teleprotection card

8-port C37.94 Teleprotection card

12-port Serial Data Interface card

16-port T1/E1 ASAP Adapter card

32-port T1/E1 ASAP Adapter card

Auxiliary Alarm card

CWDM OADM Adapter card

GNSS Receiver card

GPS Receiver module

Integrated Services card

Packet Microwave Adapter card

Power Injector card

7705 SAR-A

7705 SAR-Ax

7705 SAR-H

7705 SAR-Hc

7705 SAR-M

7705 SAR-W

7705 SAR-Wx

7705 SAR-X

3.1.3.12.1. Rate Limiting

The 7705 SAR supports egress-rate limiting and ingress-rate limiting on Ethernet ports.

The egress rate is set at the port level in the config>port>ethernet context.

Egress-rate limiting sets a limit on the amount of traffic that can leave the port to control the total bandwidth on the interface. If the egress-rate limit is reached, the port applies backpressure on the queues, which stops the flow of traffic until the queue buffers are emptied. This feature is useful in scenarios where there is a fixed amount of bandwidth; for example, a mobile operator who has leased a fixed amount of bandwidth from the service provider.

The ingress-rate command configures a policing action to rate-limit the ingress traffic. Ingress-rate enforcement uses dedicated hardware for rate limiting; however, software configuration is required at the port level (ingress-rate limiter) to ensure that the network processor or the adapter card or port never receives more traffic than they are optimized for.

The configured ingress rate ensures that the network processor does not receive traffic greater than this configured value on a per-port basis. Once the ingress-rate value is reached, all subsequent frames are dropped. The ingress-rate limiter drops excess traffic without determining whether the traffic has a higher or lower priority.

3.1.3.12.2. Access Ports

Access ports on the following can be configured for PPP/MLPPP channel groups:

  1. 2-port OC3/STM1 Channelized Adapter card
  2. 4-port OC3/STM1 / 1-port OC12/STM4 Adapter Card
  3. 12-port Serial Data Interface Card
  4. 16-port T1/E1 ASAP Adapter card
  5. 32-port T1/E1 ASAP Adapter card
  6. T1/E1 ports on the 4-port T1/E1 and RS-232 Combination module (on 7705 SAR-H)
  7. T1/E1 ports on the 7705 SAR-A (variants with T1/E1 ports)
  8. T1/E1 ports on the 7705 SAR-M (variants with T1/E1 ports)
  9. T1/E1 ports on the 7705 SAR-X

Customer IP traffic can be transported directly over PPP or MLPPP links. Access ports on the following can also be configured for TDM to transport 2G traffic from BTSs or ATM/IMA to transport 3G UMTS traffic from Node Bs:

  1. 2-port OC3/STM1 Channelized Adapter card
  2. 16-port T1/E1 ASAP Adapter card
  3. 32-port T1/E1 ASAP Adapter card
  4. T1/E1 ports on the 7705 SAR-M (variants with T1/E1 ports)

In access mode, PPP channels can be associated with n × DS0 channel groups. Although multiple PPP channel groups are supported per T1/E1 port, all the channel groups must be the same encapsulation type. For example, if one channel group on a given port is set for ipcp encapsulation, another channel group on the same port cannot be set to cem. If MLPPP channels are used, an MLPPP channel group fills up an entire DS1 or E1 link.

The 2-port OC3/STM1 Channelized Adapter card supports ipcp encapsulation of PPP/MLPPP packets for transport over an Ipipe.

The data ports on the 12-port Serial Data Interface card and the RS-232 ports on the 4-port T1/E1 and RS-232 Combination module provide transport between two data devices. Each data stream that is transported across the network can be mapped into a TDM pseudowire (Cpipe) for transport across an MPLS network. The other end can terminate either on another 7705 SAR or a multiplexer capable of terminating the pseudowire.

The 12-port Serial Data Interface card supports frame-relay encapsulation of data on V.35 and X.21 channel groups for transport over a frame relay pseudowire (Fpipe) or IP interworking pseudowire (Ipipe). The 12-port Serial Data Interface card also supports ipcp and cisco-hdlc encapsulation of PPP and Cisco HDLC packets, respectively, for transport over an Ipipe.

The 12-port Serial Data Interface card and the 4-port T1/E1 and RS-232 Combination module can also be part of a system architecture where a circuit originates on an SDI port on the 7705 SAR, transits over an MPLS network, and terminates on a 3600 MainStreet node connected to a 7705 SAR over a T1/E1 connection. In addition to the MPLS network functionality, the 12-port Serial Data Interface card and the 4-port T1/E1 and RS-232 Combination modulec can also operate in a TDM SAP-to-SAP mode where the other SAP can be another port on the 12-port Serial Data Interface card or on a T1/E1 ASAP card.

Access ports on the 8-port Ethernet Adapter card, 8-port Gigabit Ethernet Adapter card, 6-port Ethernet 10Gbps Adapter card, 10-port 1GigE/1-port 10GigE X-Adapter card (10-port 1GigE mode only), the Packet Microwave Adapter card, and the xDSL ports on the 7705 SAR-Wx, can transport traffic from sources such as e911 locators, site surveillance equipment, VoIP phones, and video cameras. The Ethernet traffic is transported over the PSN using Ethernet VLLs.

Note:

For information on VLLs, refer to the 7705 SAR Services Guide, “VLL Services”.

A microwave link from a Packet Microwave Adapter card port in access mode can peer with user equipment such as a node B or MPR-e radio. The 7705 SAR-8 and the 7705 SAR-18 treat the microwave access link as a normal SAP into a service such as Epipe, Ipipe, or VPLS/VPRN.

Voice ports on the 6-port E&M Adapter card, 8-port Voice & Teleprotection card, and 8-port FXO Adapter card provide voiceband transmission between two analog devices over a digital network. A 7705 SAR-8 or 7705 SAR-18 terminates the voice circuit and then transmits the data over a TDM-based network interface (SAP-to-SAP) or an MPLS packet-based network interface (SAP-to-SDP). For standard TDM, a T1 or E1 interface is used to transmit the data across the network.

For MPLS, any network interface (that is, Ethernet, T1/E1 MLPPP, or OC3/STM1) can be used. The traffic originating from the 6-port E&M Adapter card, 8-port Voice & Teleprotection card, or 8-port FXO Adapter card can be mapped into a TDM pseudowire (Cpipe) for transport across the MPLS network. The 6-port E&M Adapter card, and 8-port FXO Adapter card support one TDM pseudowire per port.

The voice circuit can terminate on another 7705 SAR-8 or 7705 SAR-18 over the MPLS or T1/E1 TDM connection, on other TDM-capable equipment (such as a 3600 MainStreet node) over a T1/E1 TDM connection, or on other MPLS-capable equipment over an MPLS pseudowire emulation (PWE) connection. A 3600 MainStreet or 1511 MAX can also connect to an FXO port on the 8-port Voice & Teleprotection card.

Voice ports on a 6-port FXS Adapter card can be configured for a PBX application or a PLAR (hotline) application. For a PBX application, the voice circuits are terminated on an FXO interface at a 7705 SAR hub location that is connected to a PBX. The FXO interface can be provided by either an 8-port FXO Adapter card or 8-port Voice & Teleprotection card that is installed in a 7705 SAR-8 or 7705 SAR-18 chassis at the 7705 SAR hub location.

For a PLAR application, voice circuits are terminated on an FXS interface on either another 6-port FXS Adapter card or an 8-port Voice & Teleprotection card that is installed in a 7705 SAR-8 or 7705 SAR-18 chassis located at a remote location, or terminated on a 3600 MainStreet or 1511 MAX. A hotline call can also originate from a 3600 MainStreet or 1511 MAX and terminate on an FXS interface on a 6-port FXS Adapter card (or on an FXS interface on an 8-port Voice & Teleprotection card.

On an 8-port C37.94 Teleprotection card, access traffic over the TPIF interfaces can be mapped into a TDM pseudowire (Cpipe) for transport across an MPLS network. The TPIF interfaces connect teleprotection relays used by utilities.They can also be� used with a relay to connect to a TPIF interface on an 8-port Voice & Teleprotection card or to a TPIF interface on a 1511 Media Access Cross-Connect (1511 MAX).�

SONET/SDH ports in access mode on a 4-port OC3/STM1 Clear Channel Adapter card can be configured for ATM (such as for 3G UMTS Node Bs).

The DS3/E3 clear channel access ports on the 4-port DS3/E3 Adapter card can be configured for ATM PW services (categories CBR, VBR-rt, VBR-nrt, UBR, and UBR+MCR), for TDM PW services to transport 2G traffic from BTSs, and for frame relay PW service.

Access ports on the 2-port OC3/STM1 Channelized Adapter card can be configured for TDM to transport 2G traffic from BTSs or ATM/IMA to transport 3G UMTS traffic from Node Bs. Access ports on the 4-port OC3/STM1 / 1-port OC12/STM4 Adapter card can only be configured for TDM.

All member links of the IMA group must reside on the same card. The 2G traffic is transported across the PSN encapsulated in a TDM VLL. The 3G traffic is transported using ATM VLLs.

For PPP/MLPPP channel groups, the encapsulation type must be ipcp. For Ethernet VLLs, the encapsulation type can be null, dot1q, or qinq. For TDM VLLs, the encapsulation type must be cem. For ATM VLLs, the encapsulation type must be atm.

3.1.3.12.2.1. H-QoS for Access Egress Ethernet Ports

To support hierarchical QoS (H-QoS) on second-generation Ethernet adapter cards, the 7705 SAR supports the configuration of one aggregate CIR rate for all the unshaped 4-priority access egress Ethernet SAPs on a port, thereby ensuring that all the unshaped SAPs can compete with the shaped SAPs on the port for fabric bandwidth. Use the config>port>ethernet>access>egress>unshaped-sap-cir command to set the aggregate CIR rate.

Third-generation (Gen-3) Ethernet adapter cards and platforms have 4-priority schedulers, and all SAPs are shaped SAPs. See Table 2 for a list of first-, second-, and third-generation adapter cards, modules, and platforms. Refer to the “QoS for Gen-3 Adapter Cards and Platforms” section in the 7705 SAR Quality of Service Guide for more information on 4-priority schedulers for Gen-3 hardware.

Ports on the 4-port SAR-H Fast Ethernet module do not support H-QoS.

For more information on H-QoS and on shaped and unshaped Ethernet SAPs, refer to the “Per-SAP Aggregate Shapers (H-QoS)” section in the 7705 SAR Quality of Service Guide.

3.1.3.12.3. Network Ports

Network uplinks can be configured as standalone PPP ports, or MLPPP can be configured on T1/E1 ports or channels. All member links of an MLPPP group must be of the same type (either E1 or Ds1).

The following cards, modules, and platforms support multilink bundles:

  1. T1/E1 ports on the 7705 SAR-A (variants with T1/E1 ports)
  2. T1/E1 ports on the 7705 SAR-M (variants with T1/E1 ports)
  3. T1/E1 ports on the 7705 SAR-X
    The following must have all member links of an MLPPP bundle configured on the same card or module:
    1. 16-port T1/E1 ASAP Adapter card
    2. 32-port T1/E1 ASAP Adapter card
    3. T1/E1 ports on the 4-port T1/E1 and RS-232 Combination module (on 7705 SAR-H)
    The following must have all member links of an MLPPP bundle configured on the same card or module, and on the same port:
    1. 2-port OC3/STM1 Channelized Adapter card
    2. 4-port OC3/STM1 / 1-port OC12/STM4 Adapter card

Ethernet ports on the 8-port Ethernet Adapter card, 8-port Gigabit Ethernet Adapter card, 6-port Ethernet 10Gbps Adapter card, 10-port 1GigE/1-port 10GigE X-Adapter card, and Packet Microwave Adapter card can be configured for network mode. Ethernet uplinks can be used as a cost-effective alternative to T1/E1 links.

On the 2-port 10GigE (Ethernet) Adapter card and 2-port 10GigE (Ethernet) module, the Ethernet ports and the v-port can be configured for network mode only.

A microwave link from a Packet Microwave Adapter card port in network mode provides a network uplink to an MPR-e radio. The 7705 SAR-8 or 7705 SAR-18 treats the microwave link as a Gigabit Ethernet network link with MPLS always running over it. All standard MPLS/IP functions available on a network port or SDP are also available on the microwave link.

For network uplinks on the 4-port OC3/STM1 Clear Channel Adapter card and 4-port OC3/STM1 / 1-port OC12/STM4 Adapter card, a clear channel port can be configured for POS to connect to the packet network. PPP can be enabled on a port by setting the encapsulation type to ppp-auto.

On the 2-port OC3/STM1 Channelized Adapter card, DS3 clear channels within OC3 or STM1 can be configured for PPP as the network uplink. The encapsulation type must be set to ppp-auto.

On the 4-port DS3/E3 Adapter card, a DS3/E3 clear channel port can be configured for PPP as the network uplink. The encapsulation type must be set to ppp-auto.

The 7705 SAR supports both copper and fiber uplinks.

3.1.3.12.3.1. Aggregate CIR for Unshaped VLANs on Network Egress Ethernet Ports

The 7705 SAR supports the configuration of one aggregate CIR rate for all the unshaped network egress Ethernet VLANs on a port, thereby ensuring that all the unshaped VLANs can compete with the shaped VLANs (that is, network interfaces) at the port level for egress bandwidth. Use the config>port>ethernet> network>egress>unshaped-if-cir command to set the aggregate CIR rate.

Note:

The unshaped-if-cir command does not apply to Gen-3 Ethernet adapter cards and platforms, except for network egress in hybrid mode. In this case, the shaper-if-cir command applies.

For more information on shaped and unshaped Ethernet VLANs, refer to the “Per-VLAN Network Egress Shapers” and “QoS for Gen-3 Adapter Cards and Platforms” sections in the 7705 SAR Quality of Service Guide.

3.1.3.12.4. Hybrid Ports

Hybrid ports are supported on Ethernet ports, where they provide the capabilities and features of access and network mode ports on a per-VLAN basis. The following services support hybrid port functionality: Epipe PW, Ipipe PW, IP-VPN, VPLS, and IES.

For ingress traffic, QoS and traffic management on a hybrid port behaves in the same way for access and network port modes. Refer to the 7705 SAR Quality of Service Guide, “QoS for Hybrid Ports on Gen-2 Hardware” and “QoS for Gen-3 Adapter Cards and Platforms” for details.

Network VLANs on a hybrid port provide OAM down MEP support, as well as port loopback support (in line mode with latched timers only).

The following hardware supports hybrid ports:

  1. 6-port SAR-M Ethernet module (except for the Fast Ethernet ports (ports 1 and 2))
  2. 6-port Ethernet 10Gbps Adapter card
  3. 8-port Gigabit Ethernet Adapter card
  4. 10-port 1GigE/1-port 10GigE X-Adapter card (only in 10-port 1GigE mode)
  5. Packet Microwave Adapter card (only in Ethernet port mode (not mw-link mode))
  6. 7705 SAR-A Ethernet ports (except for the Fast Ethernet ports (ports 9 to 12))
  7. 7705 SAR-Ax Ethernet ports
  8. 7705 SAR-M Ethernet ports
  9. 7705 SAR-H Ethernet ports
  10. 7705 SAR-Hc Ethernet ports
  11. 7705 SAR-W Ethernet ports
  12. 7705 SAR-Wx Ethernet ports
  13. 7705 SAR-X Ethernet ports

In some scenarios, combining the access and network capabilities under the same port is beneficial. A typical scenario is shown in Figure 1, where a single port hosts both access-side services and a traffic management model together with network-side IP/MPLS routing and switching capabilities simultaneously.

In this scenario, a network interface is configured to ensure connectivity between the cell site 7705 SAR and the aggregation site 7705 SAR. The network interface is used for all IP/MPLS traffic and is bound to VLAN-1. Another VLAN (VLAN-2) is configured to bind the management traffic of a microwave radio (an MPR-e) to an access-side service such as an Ethernet PW or VPLS. For security reasons, many mobile operators prefer to transport management traffic of network elements under a service construct as opposed to basic GRT-based routing. To accommodate this preference, an access-side service and a network interface can be configured to coexist on the same port when the port is configured for hybrid mode.

Figure 1:  Hybrid Port Application 

3.1.4. Configuring SCADA Bridges

Surveillance, Control, and Data Acquisition (SCADA) bridges are configured on an Integrated Services card as part of the multidrop data bridge (MDDB), pulse code modulation (PCM) multidrop bridge, and voice conference bridge (VCB) functionality. MDDB, PCM, and VCB are used to support SCADA systems on a 7705 SAR-8 or 7705 SAR-18.

For information on MDDB, see Multidrop Data Bridge. For information on PCM multidrop bridge, see PCM Multidrop Bridge. For information on VCB, see Voice Conference Bridge.

A SCADA bridge can be configured after the IOM is activated (the card slot and card type are designated) and the adapter card slot is preprovisioned with the Integrated Services card mda-type.

3.2. Port Features

This section contains information on the following topics:

3.2.1. Multilink Point-to-Point Protocol

This section contains information on the following topics:

3.2.1.1. MLPPP Overview

Multilink point-to-point protocol (MLPPP) is a method of splitting, recombining, and sequencing packets across multiple logical data links. MLPPP is defined in the IETF RFC 1990, The PPP Multilink Protocol (MP).

MLPPP allows multiple PPP links to be bundled together, providing a single logical connection between two routers. Data can be distributed across the multiple links within a bundle to achieve high bandwidth. As well, MLPPP allows for a single frame to be fragmented and transmitted across multiple links. This capability allows for lower latency and also for a higher maximum receive unit (MRU).

Multilink protocol is negotiated during the initial LCP option negotiations of a standard PPP session. A system indicates to its peer that it is willing to perform MLPPP by sending the MP option as part of the initial LCP option negotiation.

The system indicates the following capabilities.

  1. The system offering the option is capable of combining multiple physical links into one logical link.
  2. The system is capable of receiving upper layer protocol data units (PDUs) that are fragmented using the MP header and then reassembling the fragments back into the original PDU for processing.
  3. The system is capable of receiving PDUs of size N octets, where N is specified as part of the option, even if N is larger than the maximum receive unit (MRU) for a single physical link.

Once MLPPP has been successfully negotiated, the sending system is free to send PDUs encapsulated and/or fragmented with the MP header.

MP introduces a new protocol type with a protocol ID (PID) of 0x003d. Figure 2 and Figure 3 show the MLPPP fragment frame structure. Framing to indicate the beginning and end of the encapsulation is the same as that used by PPP and described in RFC 1662, PPP in HDLC-like Framing.

MP frames use the same HDLC address and control pair value as PPP: Address – 0xFF and Control – 0x03. The 2-octet protocol field is also structured the same way as in PPP encapsulation.

Figure 2:  MLPPP 24-bit Fragment Format 
Figure 3:  MLPPP 12-bit Fragment Format 

The required and default format for MP is the 24-bit format. During the LCP state, the 12-bit format can be negotiated. The 7705 SAR is capable of supporting and negotiating the alternate 12-bit frame format.

The maximum differential delay supported for MLPPP is 25 ms.

3.2.1.2. Protocol Field (PID)

The protocol field is two octets. Its value identifies the datagram encapsulated in the Information field of the packet. In the case of MP, the PID also identifies the presence of a 4-octet MP header (or 2-octet, if negotiated).

A PID of 0x003d identifies the packet as MP data with an MP header.

The LCP packets and protocol states of the MLPPP session follow those defined by PPP in RFC 1661. The options used during the LCP state for creating an MLPPP NCP session are described in the sections that follow.

3.2.1.3. B&E Bits

The B&E bits are used to indicate the start and end of a packet. Ingress packets to the MLPPP process will have an MTU, which may or may not be larger than the maximum received reconstructed unit (MRRU) of the MLPPP network. The B&E bits manage the fragmentation of ingress packets when the packet exceeds the MRRU.

The B-bit indicates the first (or beginning) packet of a given fragment. The E-bit indicates the last (or ending) packet of a fragment. If there is no fragmentation of the ingress packet, both B&E bits are set to true (=1).

3.2.1.4. Sequence Number

Sequence numbers can be either 12 or 24 bits long. The sequence number is 0 for the first fragment on a newly constructed bundle and increments by one for each fragment sent on that bundle. The receiver keeps track of the incoming sequence numbers on each link in a bundle and reconstructs the desired unbundled flow through processing of the received sequence numbers and B&E bits. For a detailed description of the algorithm, refer to RFC 1990.

3.2.1.5. Information Field

The Information field is zero or more octets. The Information field contains the datagram for the protocol specified in the protocol field.

The MRRU will have the same default value as the MTU for PPP. The MRRU is always negotiated during LCP.

3.2.1.6. Padding

On transmission, the Information field of the ending fragment may be padded with an arbitrary number of octets up to the MRRU. It is the responsibility of each protocol to distinguish padding octets from real information. Padding must only be added to the last fragment (E-bit set to true).

3.2.1.7. FCS

The FCS field of each MP packet is inherited from the normal framing mechanism from the member link on which the packet is transmitted. There is no separate FCS applied to the reconstituted packet as a whole if it is transmitted in more than one fragment.

3.2.1.8. LCP

The Link Control Protocol (LCP) is used to establish the connection through an exchange of configure packets. This exchange is complete, and the LCP opened state entered, once a Configure-Ack packet has been both sent and received.

LCP allows for the negotiation of multiple options in a PPP session. MP is somewhat different from PPP, and therefore the following options are set for MP and are not negotiated:

  1. no async control character map
  2. no magic number
  3. no link quality monitoring
  4. address and control field compression
  5. protocol field compression
  6. no compound frames
  7. no self-describing padding

Any non-LCP packets received during this phase must be silently discarded.

3.2.1.9. T1/E1 Link Hold Timers

T1/E1 link hold timers (or MLPPP link flap dampening) guard against the node reporting excessive interface transitions. Timers can be set to determine when link up and link down events are advertised; that is, up-to-down and down-to-up transitions of the interface are not advertised to upper layer protocols (are dampened) until the configured timer has expired.

3.2.2. Multi-Class MLPPP

The 7705 SAR supports multi-class MLPPP (MC-MLPPP) to address end-to-end delay caused by low-speed links transporting a mix of small and large packets. With MC-MLPPP, large, low-priority packets are fragmented to allow opportunities to send high-priority packets. QoS for MC-MLPPP is described in QoS in MC-MLPPP.

MC-MLPPP allows for the prioritization of multiple types of traffic flowing over MLPPP links, such as traffic between the cell site routers and the mobile operator’s aggregation routers. MC-MLPPP, as defined in RFC 2686, The Multi-Class Extension to Multi-Link PPP, is an extension of the MLPPP standard. MC-MLPPP is supported on access ports wherever PPP/MLPPP is supported, except on the 2-port OC3/STM1 Channelized Adapter card. It allows multiple classes of fragments to be transmitted over an MLPPP bundle, with each class representing a different priority level mapped to a forwarding class. The highest-priority traffic is transmitted over the MLPPP bundle with minimal delay regardless of the order in which packets are received.

Figure 4 shows the original MLPPP header format that allowed only two implied classes. The two classes were created by transmitting two interleaving flows of packets; one with MLPPP headers and one without. This resulted in two levels of priority sent over the physical link, even without the implementation of multi-class support.

Figure 5 shows the short and long sequence number fragment format MC-MLPPP headers. The short sequence number fragment format header includes two class bits to allow for up to four classes of service. Four class bits are available in the long sequence number fragment format header, but a maximum of four classes are still supported. This extension to the MLPPP header format is detailed in RFC 2686.

Figure 4:  Original MLPPP Header Format 
Figure 5:  MC-MLPPP Header Format 

The new MC-MLPPP header format uses the previously unused bits before the sequence number as the class identifier to allow four distinct classes of service to be identified.

3.2.2.1. QoS in MC-MLPPP

MC-MLPPP on the 7705 SAR supports scheduling based on multi-class implementation. Instead of the standard profiled queue-type scheduling, an MC-MLPPP encapsulated access port performs class-based traffic servicing. The four MC-MLPPP classes are scheduled in a strict priority fashion, as shown in Table 7.

Table 7:  MC-MLPPP Class Priorities 

MC-MLPPP Class

Priority

0

Priority over all other classes

1

Priority over classes 2 and 3

2

Priority over class 3

3

No priority

For example, if a packet is sent to an MC-MLPPP class 3 queue and all other queues are empty, the 7705 SAR fragments the packet according to the configured fragment size and begins sending the fragments. If a new packet arrives at an MC-MLPPP class 2 queue while the class 3 fragment is still being serviced, the 7705 SAR finishes sending any fragments of the class 3 packet that are on the wire, then holds back the remaining fragments in order to service the higher-priority packet.

The fragments of the first packet remain at the top of the class 3 queue. For packets of the same class, MC-MLPPP class queues operate on a first-in, first-out basis.

The user configures the required number of MLPPP classes to use on a bundle. The forwarding class of the packet, as determined by the ingress QoS classification, is used to determine the MLPPP class for the packet. The mapping of forwarding class to MLPPP class is a function of the user-configurable number of MLPPP classes. The mapping for 4-class, 3-class, and 2-class MLPPP bundles is shown in Table 8.

Table 8:  Packet Forwarding Class to MC-MLPPP Class Mapping  

FC ID

FC Name

MLPPP Class

4-class Bundle

MLPPP Class

3-class Bundle

MLPPP Class

2-class Bundle

7

NC

0

0

0

6

H1

0

0

0

5

EF

1

1

1

4

H2

1

1

1

3

L1

2

2

1

2

AF

2

2

1

1

L2

3

2

1

0

BE

3

2

1

If one or more forwarding classes are mapped to a queue, the scheduling priority of the queue is based on the lowest forwarding class mapped to it. For example, if forwarding classes 0 and 7 are mapped to a queue, the queue is serviced by MC-MLPPP class 3 in a 4-class bundle model.

3.2.3. cHDLC

The 7705 SAR supports Cisco HDLC, which is an encapsulation protocol for information transfer. Cisco HDLC is a bit-oriented synchronous data-link layer protocol that specifies a data encapsulation method on synchronous serial links using frame characters and checksums.

Cisco HDLC monitors line status on a serial interface by exchanging keepalive request messages with peer network devices. The protocol also allows routers to discover IP addresses of neighbors by exchanging SLARP address-request and address-response messages with peer network devices.

The basic frame structure of a cHDLC frame is shown in Table 9.

Table 9:  cHDLC Information Frame 

Flag

Address

Control

Protocol

Information

FCS

0x7E

0x0F, 0x8F

0x00

0x0800, 0x8035

16 or 32 bit

The fields in the cHDLC frame have the following characteristics:

  1. Address field—supports unicast (0x0F) and broadcast (0x8F) addresses
  2. Control field—always set to 0x00
  3. Protocol field—supports IP (0x0800) and SLARP (0x8035; see SLARP for information about limitations)
  4. Information field—the length can be 0 to 9 kbytes
  5. FCS field—can be 16 or 32 bits. The default is 16 bits for ports with a speed equal to or lower than OC3, and 32 bits for all other ports. The FCS for cHDLC is calculated with the same method and same polynomial as PPP.

3.2.3.1. SLARP

The 7705 SAR supports only the SLARP keepalive protocol.

For the SLARP keepalive protocol, each system sends the other a keepalive packet at a user configurable interval. The default interval is 10 seconds. Both systems must use the same interval to ensure reliable operation. Each system assigns sequence numbers to the keepalive packets it sends, starting with zero, independent of the other system. These sequence numbers are included in the keepalive packets sent to the other system. Also included in each keepalive packet is the sequence number of the last keepalive packet received from the other system, as assigned by the other system. This number is called the returned sequence number. Each system keeps track of the last returned sequence number it has received. Immediately before sending a keepalive packet, the system compares the sequence number of the packet it is about to send with the returned sequence number in the last keepalive packet it has received. If the two differ by 3 or more, it considers the line to have failed, and will not route higher-level data across it until an acceptable keepalive response is received.

3.2.4. Inverse Multiplexing Over ATM (IMA)

IMA is a cell-based protocol where an ATM cell stream is inverse-multiplexed and demultiplexed in a cyclical fashion among ATM-supporting channels to form a higher bandwidth logical link. This logical link is called an IMA group. By grouping channels into an IMA group, customers gain bandwidth management capability at in-between rates (for example, between DS1 and DS3 or between E1 and E3) through the addition or removal of channels to or from the IMA group. The 7705 SAR supports the IMA protocol as specified by the Inverse Multiplexing for ATM (IMA) Specification version 1.1.

In the ingress direction, traffic coming over multiple ATM channels configured as part of a single IMA group is converted into a single ATM stream and passed for further processing to the ATM layer, where service-related functions (for example, Layer 2 traffic management or feeding into a pseudowire) are applied. In the egress direction, a single ATM stream (after service functions are applied) is distributed over all paths that are part of an IMA group after ATM layer processing takes place.

An IMA group interface compensates for differential delay and allows for only a minimal cell delay variation. The maximum differential delay supported for IMA is 75 ms on 16-port T1/E1 ASAP Adapter cards and 32-port T1/E1 ASAP Adapter cards and 50 ms on 2-port OC3/STM1 Channelized Adapter cards.

The interface deals with links that are added or deleted, or that fail. The higher layers see only an IMA group and not individual links; therefore, service configuration and management is done using IMA groups, and not individual links that are part of it.

The IMA protocol uses an IMA frame as the unit of control. An IMA frame consists of a series of 128 consecutive cells. In addition to ATM cells received from the ATM layer, the IMA frame contains IMA OAM cells. Two types of cells are defined: IMA Control Protocol (ICP) cells and IMA filler cells. ICP cells carry information used by the IMA protocol at both ends of an IMA group (for example, IMA frame sequence number, link stuff indication, status and control indication, IMA ID, Tx and Rx test patterns, version of the IMA protocol). A single ICP cell is inserted at the ICP cell offset position (the offset may be different on each link of the group) of each frame. Filler cells are used by the transmitting side to fill up each IMA frame in case there are not enough ATM stream cells from the ATM layer, so a continuous stream of cells is presented to the physical layer. Those cells are then discarded by the receiving end. IMA frames are transmitted simultaneously on all paths of an IMA group, and when they are received out of sync at the other end of the IMA group link, the receiver compensates for differential link delays among all paths.

3.2.5. Network Synchronization on Ports and Circuits

The 7705 SAR provides network synchronization on the following ports and CES circuits:

3.2.5.1. Network Synchronization on T1/E1, Ethernet, GPON, and DSL Ports

Line timing mode provides physical layer timing (Layer 1) that can be used as an accurate reference for nodes in the network. This mode is immune to any packet delay variation (PDV) occurring on a Layer 2 or Layer 3 link. Physical layer timing provides the best synchronization performance through a synchronization distribution network.

On the 7705 SAR-A variant with T1/E1 ports, line timing is supported on T1/E1 ports. Line timing is also supported on all synchronous Ethernet ports on both 7705 SAR-A variants. Synchronous Ethernet is supported on the XOR ports (1 to 4), configured as either RJ-45 ports or SFP ports. Synchronous Ethernet is also supported on SFP ports 5 to 8. Ports 9 to 12 do not support synchronous Ethernet and, therefore, do not support line timing.

On the 7705 SAR-Ax, line timing is supported on all Ethernet ports.

On the 7705 SAR-H, line timing is supported on:

  1. all Ethernet ports
  2. T1/E1 ports on a chassis equipped with a 4-port T1/E1 and RS-232 Combination module

On the 7705 SAR-Hc, line timing is supported on all Ethernet ports.

On the 7705 SAR-M (variants with T1/E1 ports), line timing is supported on T1/E1 ports. Line timing is also supported on all RJ-45 Ethernet ports and SFP ports on the 7705 SAR-M (all variants).

On the 7705 SAR-W, line timing is supported on:

  1. RJ-45 Ethernet ports and optical SFP ports (these ports support synchronous Ethernet and IEEE 1588v2 PTP)

On the 7705 SAR-Wx, line timing is supported on:

  1. RJ-45 Ethernet ports and optical SFP ports (these ports support synchronous Ethernet and IEEE 1588v2 PTP)

On the 7705 SAR-X, line timing is supported on T1/E1 ports and Ethernet ports.

In addition, line timing is supported on the following modules when they are installed in chassis variants with module slots:

  1. GPON module
  2. 8-port xDSL module (NTR over ADSL2, ADSL2+, or VDSL2)
  3. 6-port DSL Combination module (two references are available: NTR over SHDSL and NTR over ADSL2, ADSL2+, or VDSL2)
  4. 2-port 10GigE (Ethernet) module
  5. 6-port SAR-M Ethernet module

On the 7705 SAR-8 and 7705 SAR-18, line timing is supported on:

  1. 16-port T1/E1 ASAP Adapter card (version 1 is not supported on the 7705 SAR-18)
  2. 32-port T1/E1 ASAP Adapter card
  3. 8-port Ethernet Adapter card, version 2, on the two Ethernet SFP ports with SFPs that support synchronous Ethernet
  4. 6-port Ethernet 10Gbps Adapter card
  5. 8-port Gigabit Ethernet Adapter card (dual-rate and copper SFPs do not support synchronous Ethernet)
  6. 2-port 10GigE (Ethernet) Adapter card
  7. 10-port 1GigE/1-port 10GigE X-Adapter card (not supported on the 7705 SAR-8)
  8. 4-port DS3/E3 Adapter card
  9. 2-port OC3/STM1 Channelized Adapter card
  10. 4-port OC3/STM1 / 1-port OC12/STM4 Adapter card
  11. 4-port OC3/STM1 Clear Channel Adapter card
  12. Packet Microwave Adapter card on ports that support synchronous Ethernet and on ports that support PCR

Synchronous Ethernet is a variant of line timing and is automatically enabled on ports and SFPs that support it. The operator can select a synchronous Ethernet port as a candidate for the timing reference. The recovered timing from this port is then used to time the system. This ensures that any of the system outputs are locked to a stable, traceable frequency source.

3.2.5.2. Network Synchronization on SONET/SDH Ports

Each SONET/SDH port can be independently configured to be loop-timed (recovered from an Rx line) or node-timed (recovered from the SSU in the active CSM).

A SONET/SDH port’s receive clock rate can be used as a synchronization source for the node.

3.2.5.3. Network Synchronization on DS3/E3 Ports

Each clear channel DS3/E3 port on a 4-port DS3/E3 Adapter card can be independently configured to be loop-timed (recovered from an Rx line), node-timed (recovered from the SSU in the active CSM), or differential-timed (derived from the comparison of a common clock to the received RTP timestamp in TDM pseudowire packets). When a DS3 port is channelized, each DS1 or E1 channel can be independently configured to be loop-timed, node-timed, or differential-timed (differential timing on DS1/E1 channels is supported only on the first three ports of the card). When not configured for differential timing, a DS3/E3 port can be configured to be a timing source for the node.

3.2.5.4. Network Synchronization on DS3 CES Circuits

Each DS3 CES circuit on a 2-port OC3/STM1 Channelized Adapter card card can be loop-timed (recovered from an Rx line) or free-run (timing source is from its own clock). A DS3 circuit can be configured to be a timing source for the node.

3.2.5.5. Network Synchronization on T1/E1 Ports and Circuits

Each T1/E1 port can be independently configured for loop-timing (recovered from an Rx line) or node-timing (recovered from the SSU in the active CSM).

In addition, T1/E1 CES circuits on the following can be independently configured for adaptive timing (clocking is derived from incoming TDM pseudowire packets):

  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. 7705 SAR-X
  5. 7705 SAR-A (variant with T1/E1 ports)
  6. T1/E1 ports on the 4-port T1/E1 and RS-232 Combination module

T1/E1 CES circuits on the following can be independently configured for differential timing (recovered from RTP in TDM pseudowire packets):

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

A T1/E1 port can be configured to be a timing source for the node.

Note:

Adaptive timing and differential timing are not supported on DS1 or E1 channels that have CAS signaling enabled.

3.2.6. Node Synchronization From GNSS Receiver Ports

The GNSS receiver port on the 7705 SAR-Ax, 7705 SAR-Wx, and 7705 SAR-H GPS Receiver module, and the GNSS Receiver card installed in a 7705 SAR-8 or 7705 SAR-18, can provide a synchronization clock to the SSU in the router with the corresponding QL for SSM. This frequency can then be distributed to the rest of the router from the SSU as configured with the ref-order and ql-selection commands; refer to the 7705 SAR Basic System Configuration Guide for information. The GNSS reference is qualified only if the GNSS receiver port is operational, has sufficient satellites locked, and has a frequency successfully recovered. A PTP master/boundary clock can also use this frequency reference with PTP peers.

In the event of GNSS signal loss or jamming resulting in the unavailability of timing information, the GNSS receiver automatically prevents output of clock or synchronization data to the system, and the system can revert to alternate timing sources.

A 7705 SAR using GNSS or IEEE 1588v2 PTP for time of day/phase recovery can perform high-accuracy OAM timestamping and measurements. Refer to the 7705 SAR Basic System Configuration Guide for information about node timing sources.

3.2.7. Flow Control on Ethernet Ports

IEEE 802.3x Flow Control, which is the process of pausing the transmission based on received pause frames, is supported on Fast Ethernet, Gigabit Ethernet, and 10-Gigabit Ethernet (SFP+) ports. In the transmit direction, the Ethernet ports generate pause frames if the buffer occupancy reaches critical values or if port FIFO buffers are overloaded. Pause frame generation is automatically handled by the Ethernet Adapter card when the system-wide constant thresholds are exceeded. The generation of pause frames ensures that newly arriving frames still can be processed and queued, mainly to maintain the SLA agreements.

If autonegotiation is on for an Ethernet port, enabling and disabling of IEEE 802.3x Flow Control is autonegotiated for receive and transmit directions separately. If autonegotiation is turned off, the reception and transmission of IEEE 802.3x Flow Control is enabled by default and cannot be disabled.

Ingress flow control for the 6-port SAR-M Ethernet module is Ethernet link-based and not port-based. When IEEE 802.3x Flow Control is enabled on the 6-port SAR-M Ethernet module, pause frames are multicast to all ports on the Ethernet link. There are two Ethernet links on the 6-port SAR-M Ethernet module: one for ports 1, 3, and 5, and one for ports 2, 4, and 6. Pause frames are sent to either ports 1, 3, and 5, or to ports 2, 4, and 6, depending on which link the pause frame originates.

3.2.8. Ethernet OAM

This section contains information on the following topics:

For more information on Ethernet OAM, refer to the 7705 SAR OAM and Diagnostics Guide, “Ethernet OAM Capabilities”.

3.2.8.1. Ethernet OAM Overview

802.3ah Clause 57 (EFM OAM) defines the Operations, Administration, and Maintenance (OAM) sublayer, which is a link level Ethernet OAM. It provides mechanisms for monitoring link operations such as remote fault indication and remote loopback control.

Ethernet OAM gives network operators the ability to monitor the status of Ethernet links and quickly determine the location of failing links or fault conditions.

Because some of the sites where the 7705 SAR will be deployed will only have Ethernet uplinks, this OAM functionality is mandatory. For example, mobile operators must be able to request remote loopbacks from the peer router at the Ethernet layer in order to debug any connectivity issues. EFM OAM provides this capability.

EFM OAM is supported on network and access Ethernet and DSL ports and is configured at the port level. The access ports can be configured to tunnel the OAM traffic originated by the far-end devices. EFM OAM is not supported on the 7705 SAR-M GPON module.

EFM OAM has the following characteristics.

  1. All EFM OAM, including loopbacks, operate on point-to-point links only.
  2. EFM loopbacks are always line loopbacks (line Rx to line Tx). Line loopbacks are not supported on DSL ports.
  3. When a port is in loopback, all frames (except EFM frames) are discarded. If dynamic signaling and routing is used (dynamic LSPs, OSPF, IS-IS, or BGP routing), all services also go down. If all signaling and routing protocols are static (static routes, LSPs, and service labels), the frames are discarded but services stay up.

The following EFM OAM functions are supported:

  1. OAM capability discovery
  2. configurable transmit interval with an Information OAMPDU
  3. active or passive mode
  4. OAM loopback
  5. OAMPDU tunneling and termination (for Epipe service)
  6. dying gasp at network and access ports
  7. non-zero vendor-specific information field — the 32-bit field is encoded using the format 00:PP:CC:CC and references TIMETRA-CHASSIS-MIB
    1. 00 — must be zeros
    2. PP — the platform type from tmnxHwEquippedPlatform
    3. CC:CC — the chassis type index value from tmnxChassisType that is indexed in tmnxChassisTypeTable. The table identifies the specific chassis backplane.
      The value 00:00:00:00 is sent for all releases that do not support the non-zero value or are unable to identify the required elements. There is no decoding of the peer or local vendor information fields on the network element. The hexadecimal value is included in the show port port-id ethernet efm-oam output.

With ignore-efm-state configured, if the EFM OAM protocol cannot negotiate a peer session or an established session fails, the port will enter the link up state. The link up state is used by many protocols to indicate that the port is administratively up and there is physical connectivity but a protocol (such as EFM OAM) has caused the port operational state to be down. The show port slot/mda/port command output includes a Reason Down field to indicate if the protocol is the underlying reason for the link up state. For EFM OAM, the Reason Down code is efmOamDown. This is shown in the following command output example, where port 1/1/3 is in a link up state.

*A:ALU-1># show port
===============================================================================
Ports on Slot 1
===============================================================================
Port        Admin Link Port    Cfg  Oper LAG/ Port Port Port   C/QS/S/XFP/
Id          State      State   MTU  MTU  Bndl Mode Encp Type   MDIMDX
-------------------------------------------------------------------------------
1/1/1       Down  No   Down    1578 1578    - netw null xcme
1/1/2       Down  No   Down    1578 1578    - netw null xcme
1/1/3       Up    Yes  Link Up 1522 1522    - accs qinq xcme
1/1/4       Down  No   Down    1578 1578    - netw null xcme
1/1/5       Down  No   Down    1578 1578    - netw null xcme
1/1/6       Down  No   Down    1578 1578    - netw null xcme
 
*A:ALU-1># show port 1/1/3
===============================================================================
Ethernet Interface
===============================================================================
Description        : 10/100/Gig Ethernet SFP
Interface          : 1/1/3                      Oper Speed       : N/A
Link-level         : Ethernet                   Config Speed     : 1 Gbps
Admin State        : up                         Oper Duplex      : N/A
Oper State         : down                       Config Duplex    : full
Reason Down        : efmOamDown
Physical Link      : Yes                        MTU              : 1522
Single Fiber Mode  : No                         Min Frame Length : 64 Bytes
IfIndex            : 35749888                   Hold time up     : 0 seconds
Last State Change  : 12/18/2012 15:58:29        Hold time down   : 0 seconds
Last Cleared Time  : N/A                        DDM Events       : Enabled
Phys State Chng Cnt: 1
 
......

The EFM OAM protocol can be decoupled from the port state and operational state. In cases where an operator wants to remove the protocol, monitor only the protocol, migrate, or make changes, the ignore-efm-state command can be configured under the config>port>ethernet>efm-oam context.

When the ignore-efm-state command is configured on a port, the protocol behavior is normal. However, any failure in the EFM protocol state (discovery, configuration, time-out, loops, and so on) will not affect the port. Only a protocol warning message will be raised to indicate issues with the protocol. When the ignore-efm-state command is not configured on a port, the default behavior is that the port state will be affected by any EFM OAM protocol fault or clear conditions.

Enabling and disabling this command will immediately affect the port state and operating state based on the active configuration, and this will be displayed in the show port command output. For example, if the ignore-efm-state command is configured on a port that is exhibiting a protocol error, that protocol error does not affect the port state or operational state and there is no Reason Down code in the output. If the ignore-efm-state command is disabled on a port with an existing EFM OAM protocol error, the port will transition to port state link up, operational state down with reason code efmOamDown.

If the port is a member of a microwave link, the ignore-efm-state command must be enabled before the EFM OAM protocol can be activated. This restriction is required because EFM OAM is not compatible with microwave links.

3.2.8.2. CRC (Cyclic Redundancy Check) Monitoring

CRC errors typically occur when Ethernet links are compromised due to optical fiber degradation, weak optical signals, bad optical connections, or problems on a third-party networking element. As well, higher-layer OAM options such as EFM and BFD may not detect errors and trigger appropriate alarms and switchovers if the errors are intermittent, since this does not affect the continuous operation of other OAM functions.

CRC error monitoring on Ethernet ports allows degraded links to be alarmed or failed in order to detect network infrastructure issues, trigger necessary maintenance, or switch to redundant paths. This is achieved through monitoring ingress error counts and comparing them to the configured error thresholds. The rate at which CRC errors are detected on a port can trigger two alarm states. Crossing the configured signal degrade (SD) threshold (sd-threshold) causes an event to be logged and an alarm to be raised, which alerts the operator to a potential issue on a link. Crossing the configured signal failure (SF) threshold (sf-threshold) causes the affected port to enter the operationally down state, and causes an event to be logged and an alarm to be raised.

The CRC error rates are calculated as M×10E-N, which is the ratio of errored frames allowed for total frames received. The operator can configure both the threshold (N) and a multiplier (M). If the multiplier is not configured, the default multiplier (1) is used.

For example, setting the SD threshold to 3 results in a signal degrade error rate threshold of 1×10E-3 (1 errored frame per 1000 frames). Changing the configuration to an SD threshold of 3 and a multiplier of 5 results in a signal degrade error rate threshold of 5×10E-3 (5 errored frames per 1000 frames). The signal degrade error rate threshold must be lower than the signal failure error rate threshold because it is used to notify the operator that the port is operating in a degraded but not failed condition.

A sliding window (window-size) is used to calculate a statistical average of CRC error statistics collected every second. Each second, the oldest statistics are dropped from the calculation. For example, if the default 10-s sliding window is configured, at the 11th second the oldest second of statistical data is dropped and the 11th second is included. This sliding average is compared against the configured SD and SF thresholds to determine if the error rate over the window exceeds one or both of the thresholds, which will generate an alarm and log event.

When a port enters the failed condition as a result of crossing an SF threshold, the port is not automatically returned to service. Because the port is operationally down without a physical link, error monitoring stops. The operator can enable the port by using the shutdown and no shutdown port commands or by using other port transition functions such as clearing the MDA (clear mda command) or removing the cable. A port that is down due to crossing an SF threshold can also be re-enabled by changing or disabling the SD threshold. The SD state is self-clearing, and it clears if the error rate drops below 1/10th of the configured SD rate.

Note:

CRC monitoring is not supported on GPON or DSL ports.

3.2.8.3. Remote Loopback

EFM OAM provides a link-layer frame loopback mode, which can be controlled remotely.

To initiate a remote loopback, the local EFM OAM client sends a loopback control OAMPDU by enabling the OAM remote loopback command. After receiving the loopback control OAMPDU, the remote OAM client puts the remote port into local loopback mode.

OAMPDUs are slow protocol frames that contain appropriate control and status information used to monitor, test, and troubleshoot OAM-enabled links.

To exit a remote loopback, the local EFM OAM client sends a loopback control OAMPDU by disabling the OAM remote loopback command. After receiving the loopback control OAMPDU, the remote OAM client puts the port back into normal forwarding mode.

When a port is in local loopback mode (the far end requested an Ethernet OAM loopback), any packets received on the port will be looped back, except for EFM OAMPDUs. No data will be transmitted from the node; only data that is received on the node will be sent back out.

When the node is in remote loopback mode, local data from the CSM is transmitted, but any data received on the node is dropped, except for EFM OAMPDUs.

Remote loopbacks should be used with caution; if dynamic signaling and routing protocols are used, all services go down when a remote loopback is initiated. If only static signaling and routing is used, the services stay up. On the 7705 SAR, the Ethernet port can be configured to accept or reject the remote-loopback command.

3.2.8.4. 802.3ah OAMPDU Tunneling and Termination for Epipe Service

Customers who subscribe to Epipe service might have customer equipment running 802.3ah at both ends. The 7705 SAR can be configured to tunnel EFM OAMPDUs received from a customer device to the other end through the existing network using MPLS or GRE, or to terminate received OAMPDUs at a network or an access Ethernet port.

Note:

This feature applies only to port-based Epipe SAPs because 802.3ah runs at port level, not at VLAN level.

While tunneling offers the ability to terminate and process the OAM messages at the head-end, termination on the first access port at the cell site can be used to detect immediate failures or can be used to detect port failures in a timelier manner. The user can choose either tunneling or termination, but not both at the same time.

In Figure 6, scenario 1 shows the termination of received EFM OAMPDUs from a customer device on an access port, while scenario 2 shows the same thing except for a network port. Scenario 3 shows tunneling of EFM OAMPDUs through the associated Ethernet PW. To configure termination (scenario 1), use the config>port>ethernet>efm-oam>no shutdown command.

Figure 6:  EFM Capability on the 7705 SAR 

3.2.8.5. Dying Gasp

Dying gasp is used to notify the far end that EFM-OAM is disabled or shut down on the local port. The dying gasp flag is set on the OAMPDUs that are sent to the peer. The far end can then take immediate action and inform upper layers that EFM-OAM is down on the port.

When a dying gasp is received from a peer, the node logs the event and generates an SNMP trap to notify the operator.

3.2.9. Ethernet Loopbacks

This section contains information on the following topics:

Table 10 lists the loopbacks supported on Ethernet, DSL module (6-port DSL Combination module and 8-port xDSL module), and GPON module ports.

Table 10:  Loopbacks Supported on Ethernet, DSL, and GPON Ports 

Loopback

Ethernet

DSL

GPON

Timed network line loopback

Timed and untimed access line loopbacks

Timed and untimed access internal loopbacks

Persistent access line loopback

Persistent access internal loopback

MAC address swapping

CFM loopback on network and access ports

CFM loopback on ring ports and v-port

3.2.9.1. Line and Internal Ethernet Loopbacks

A line loopback loops frames received on the corresponding port back towards the transmit direction. Line loopbacks are supported on ports configured for access or network mode.

Similarly, a line loopback with MAC addressing loops frames received on the corresponding port back towards the transmit direction, and swaps the source and destination MAC addresses before transmission. See MAC Swapping for more information.

An internal loopback loops frames from the local router back to the framer. This is usually referred to as an equipment loopback. The transmit signal is looped back and received by the interface. Internal loopbacks are supported on ports configured in access mode.

If a loopback is enabled on a port, the port mode cannot be changed until the loopback has been disabled.

A port can support only one loopback at a time. If a loopback exists on a port, it must be disabled or the timer must expire before another loopback can be configured on the same port. EFM-OAM cannot be enabled on a port that has an Ethernet loopback enabled on it. Similarly, an Ethernet loopback cannot be enabled on a port that has EFM-OAM enabled on it.

When an internal loopback is enabled on a port, autonegotiation is turned off silently. This is to allow an internal loopback when the operational status of a port is down. Any user modification to autonegotiation on a port configured with an internal Ethernet loopback will not take effect until the loopback is disabled.

The loopback timer can be configured from 30 s to 86400 s. All non-zero timed loopbacks are turned off automatically under the following conditions: an adapter card reset, DSL module reset, GPON module reset, an activity switch, or timer expiry. Line or internal loopback timers can also be configured as a latched loopback by setting the timer to 0 s, or as a persistent loopback with the persistent keyword. Latched and persistent loopbacks are enabled indefinitely until turned off by the user. Latched loopbacks survive adapter card resets and activity switches, but are lost if there is a system restart. Persistent loopbacks survive adapter card resets and activity switches and can survive a system restart if the admin-save or admin-save-detail command was executed prior to the restart. Latched loopbacks (untimed) and persistent loopbacks can be enabled only on Ethernet access ports.

Persistent loopbacks are the only Ethernet loopbacks saved to the database by the admin-save and admin-save-detail commands.

An Ethernet port loopback may interact with other features. See Interaction of Ethernet Port Loopback with Other Features for more information.

3.2.9.1.1. MAC Swapping

Typically, an Ethernet port loopback only echoes back received frames. That is, the received source and destination MAC addresses are not swapped. However, not all Ethernet equipment supports echo mode, where the original sender of the frame must support receiving its own port MAC address as the destination MAC address.

The MAC swapping feature on the 7705 SAR is an optional feature that will swap the received destination MAC address with the source MAC address when an Ethernet port is in loopback mode. After the swap, the FCS is recalculated to ensure the validity of the Ethernet frame and to ensure that the frame is not dropped by the original sender due to a CRC error.

MAC swapping is not supported on the GPON module, 6-port DSL Combination module, or 8-port xDSL module.

3.2.9.1.2. Interaction of Ethernet Port Loopback with Other Features

EFM OAM and line loopback are mutually exclusive. If one of these functions is enabled, it must be disabled before the other can be used.

However, a line loopback precedes the dot1x behavior. That is, if the port is already dot1x-authenticated it will remain so. If it is not, EAP authentication will fail.

Ethernet port-layer line loopback and Ethernet port-layer internal loopback can be enabled on the same port with the down-when-looped feature. EFM OAM cannot be enabled on the same port with the down-when-looped feature. For more information, see Ethernet Port Down-When-Looped.

3.2.9.2. CFM Loopbacks for OAM on Ethernet Ports

This section contains information on the following topics:

3.2.9.2.1. CFM Loopback Overview

Connectivity fault management (CFM) loopback support for loopback messages (LBMs) on Ethernet ports allows operators to run standards-based Layer 1 and Layer 2 OAM tests on ports receiving unlabeled packets.

The 7705 SAR supports CFM MEPs associated with different endpoints (that is, spoke SDP Down MEPs, network interface facility MEPs, and SAP Up and SAP Down MEPs). In addition, for traffic received from an uplink (network ingress), the 7705 SAR supports CFM LBM for both labeled and unlabeled packets. CFM loopbacks are applied to the Ethernet port.

Refer to the 7705 SAR OAM and Diagnostics Guide, “Ethernet OAM Capabilities”, for information on CFM MEPs.

Figure 7 shows an application where an operator leases facilities from a transport network provider in order to transport traffic from a cell site to their MTSO. The operator leases a certain amount of bandwidth between the two endpoints (the cell site and the MTSO) from the transport provider, who offers Ethernet Virtual Private Line (EVPL) or Ethernet Private Line (EPL) PTP service. Before the operator offers services on the leased bandwidth, the operator runs OAM tests to verify the SLA. Typically, the transport provider (MEN provider) requires that the OAM tests be run in the direction of (towards) the first Ethernet port that is connected to the transport network. This is done in order to eliminate the potential effect of queuing, delay, and jitter that may be introduced by a spoke SDP or SAP.

Figure 7:  CFM Loopback on Ethernet Ports 

Figure 7 shows an Ethernet verifier at the MTSO that is directly connected to the transport network (in front of the 7750 SR). Thus, the Ethernet OAM frames are not label-encapsulated. Given that Ethernet verifiers do not support label operations and the transport provider mandates that OAM tests be run between the two hand-off Ethernet ports, the verifier cannot be relocated behind the 7750 SR node at the MTSO. Therefore, CFM loopback frames received are not MPLS-encapsulated, but are simple Ethernet frames where the type is set to CFM (dot1ag or Y.1731).

3.2.9.2.2. CFM Loopback Mechanics

The following list contains important facts to consider when working with CFM loopbacks:

  1. CFM loopbacks can be enabled on a per-port basis, and:
    1. the port can be in access or network mode
    2. once enabled on a port, all received LBM frames are processed, regardless of the VLAN and the service that the VLAN or SAP is bound to
    3. there is no associated MEP creation involved with this feature; therefore, no domain, association, or similar checks are performed on the received frame
    4. upon finding a destination address MAC match, the LBM frame is sent to the CFM process
  2. CFM loopback support on a physical ring port on the 2-port 10GigE (Ethernet) Adapter card or 2-port 10GigE (Ethernet) module differs from other Ethernet ports. For these ports, cfm-loopback is configured, optionally, using dot1p and match-vlan to create a list of up to 16 VLANs. The null VLAN is always applied. The CFM Loopback Message will be processed if it does not contain a VLAN header, or if it contains a VLAN header with a VLAN ID that matches one in the configured match-vlan list.
  3. received LBM frames undergo no queuing or scheduling in the ingress direction
  4. at egress, loopback reply (LBR) frames are stored in their own queue; that is, a separate new queue is added exclusively for LBR frames
  5. users can configure the way a response frame is treated among other user traffic stored in network queues; the configuration options are high-priority, low-priority, or dot1p, where dot1p applies only to physical ring ports
  6. for network egress, where profiled scheduling is enabled, the following conditions apply:
    1. high-priority: either cir = port_speed, which applies to all frames that are scheduled via an in-profile scheduler; or round-robin (RR) for all other (network egress queue) frames that are in-profile
    2. low-priority: either cir = 0, pir = port_speed, which applies to all frames that are scheduled as out-of-profile, or RR for all other frames that are out-of-profile
  7. for network egress or access egress, where 4-priority scheduling is enabled:
    1. high-priority: either cir = port_speed, which applies to all frames that are scheduled via an expedited in-profile scheduler, or RR for all other (network egress queue) frames that reside in expedited queues and are in an in-profile state
    2. low-priority: either cir = 0, pir = port_speed, which applies to all frames that are scheduled via a best effort out-of-profile scheduler, or RR for all other frames that reside in best-effort queues and are in an out-of-profile state
  8. for the 8-port Gigabit Ethernet Adapter card, the 10-port 1GigE/1-port 10GigE X-Adapter card, and the v-port on the 2-port 10GigE (Ethernet) Adapter card and 2-port 10GigE (Ethernet) module, for network egress, where 16-priority scheduling is enabled:
    1. high-priority: has higher priority than any user frames
    2. low-priority: has lower priority than any user frames
  9. for the physical ring ports on the 2-port 10GigE (Ethernet) Adapter card and 2-port 10GigE (Ethernet) module, which can only operate as network egress, the priority of the LBR frame is derived from the dot1p setting of the received LBM frame. Based on the assigned ring-type network queue policy, dot1p-to-queue mapping is handled using the same mapping rule that applies to all other user frames.
  10. the above queue parameters and scheduler mappings are all preconfigured and cannot be altered. The desired QoS treatment is selected by enabling the CFM loopback and specifying high-priority, low-priority, or dot1p.

3.2.10. Ethernet Port Down-When-Looped

Newly provisioned circuits are often put into loopback with a physical loopback cable for testing and to ensure the ports meet the SLA. If loopbacks are not cleared, or physically removed, by the operator when the testing is completed, they can adversely affect the performance of all other SDPs and customer interfaces (SAPs). This is especially problematic for point-to-multipoint services such as VPLS, since Ethernet does not support TTL, which is essential in terminating loops.

The down-when-looped feature is used on the 7705 SAR to detect loops within the network and to ensure continued operation of other ports. When the down-when-looped feature is activated, a keepalive loop PDU is transmitted periodically toward the network. The Ethernet port then listens for returning keepalive loop PDUs. In unicast mode, a loop is detected if any of the received PDUs have an Ethertype value of 9000, which indicates a loopback (Configuration Test Protocol), and the source (SRC) and destination (DST) MAC addresses are identical to the MAC address of the Ethernet port. In broadcast mode, a loop is detected if any of the received PDUs have an Ethertype value of 9000 and the SRC MAC address matches the MAC address of the Ethernet port and the DST MAC address matches the broadcast MAC address. When a loop is detected, the Ethernet port is immediately brought down. Down-when-looped is supported on Ethernet ports, DSL module ports, and GPON module ports.

Ethernet port-layer line loopbacks and the down-when-looped feature can be enabled on the same port. The keepalive loop PDU is still transmitted; however, if the port receives its own keepalive loop PDU, the keepalive PDU is extracted and processed to avoid infinite looping.

Ethernet port-layer internal loopbacks and the down-when-looped feature can also be enabled on the same port. When the keepalive PDU is internally looped back, it is extracted and processed as usual. If the SRC MAC address matches the port MAC address, the port is disabled due to detection of a loop. If the SRC MAC address is a broadcast MAC address because the swap-src-dst-mac option in the loopback command is enabled, then there is no change to port status and it remains operationally up.

EFM OAM and down-when-looped cannot be enabled on the same port.

3.2.11. Ethernet Ring (Adapter Card and Module)

The 2-port 10GigE (Ethernet) Adapter card can be installed in a 7705 SAR-8 or 7705 SAR-18 chassis and the 2-port 10GigE (Ethernet) module can be installed in a 7705 SAR-M to connect to and from access rings carrying a high concentration of traffic. For the maximum number of cards or modules supported per chassis, see Table 3.

A number of 7705 SAR nodes in a ring typically aggregate traffic from customer sites, map the traffic to a service, and connect to an SR node. The SR node acts as a gateway point out of the ring. A 10GigE ring allows for higher bandwidth services and aggregation on a per-7705 SAR basis. The 2-port 10GigE (Ethernet) Adapter card/module increases the capacity of backhaul networks by providing 10GigE support on the aggregation nodes, thus increasing the port capacity.

In a deployment of a 2-port 10GigE (Ethernet) Adapter card/module, each 7705 SAR node in the ring is connected to the east and west side of the ring over two different 10GigE ports. If 10GigE is the main uplink, the following are required for redundancy:

  1. two cards per 7705 SAR-8
  2. two cards per 7705 SAR-18
  3. two 7705 SAR-M nodes, each equipped with 2-port 10GigE (Ethernet) module

With two cards per 7705 SAR-8 or 7705 SAR-18 node, for example, east and west links of the ring can be terminated on two different adapter cards, reducing the impact of potential hardware failure.

The physical ports on the 2-port 10GigE (Ethernet) Adapter card/module boot up in network mode and this network setting cannot be disabled or altered. At boot-up, the MAC address of the virtual port (v-port) is programmed automatically for efficiency and security reasons.

There is native built-in Ethernet bridging among the ring ports and the v-port. Bridging destinations for traffic received from one of the ring ports include the 10GigE ring port and the network interfaces on the v-port. Bridging destinations for traffic received from the v-port include one or both of the 10GigE ring ports.

With bridging, broadcast and multicast frames are forwarded over all ports except the received one. Unknown frames are forwarded to both 10GigE ports if received from the v-port or forwarded to the other 10GigE port only if received from one of the 10GigE ports (the local v-port MAC address is always programmed).

The bridge traffic of the physical 10GigE ports is based on learned and programmed MAC addresses.

3.2.12. MTU Configuration Guidelines

This section contains information on the following topics:

3.2.12.1. MTU Configuration Overview

Because of the services overhead (that is, pseudowire/VLL, MPLS tunnel, dot1q/qinq and dot1p overhead), it is crucial that configurable variable frame size be supported for end-to-end service delivery.

Observe the following general rules when planning your service and physical Maximum Transmission Unit (MTU) configurations.

  1. The 7705 SAR must contend with MTU limitations at many service points. The physical (access and network) port, service, and SDP MTU values must be individually defined. Figure 8 identifies the various MTU points on the 7705 SAR.
  2. The ports that will be designated as network ports intended to carry service traffic must be identified.
  3. MTU values should not be modified frequently.
  4. MTU values must conform to both of the following conditions:
    1. the service MTU must be less than or equal to the SDP path MTU
    2. the service MTU must be less than or equal to the access port (SAP) MTU
  5. When the allow-fragmentation command is enabled on an SDP, the current MTU algorithm is overwritten with the configured path MTU. The administrative MTU and operational MTU both show the specified MTU value. If the path MTU is not configured or available, the operational MTU is set to 2000 bytes, and the administrative MTU displays a value of 0. When allow-fragmentation is disabled, the operational MTU reverts to the previous value.

For more information, refer to the “MTU Settings” section in the 7705 SAR Services Guide. To configure various MTU points, use the following commands:

  1. port MTUs are set with the mtu command, under the config>port context, where the port type can be Ethernet, DSL, GPON, TDM, serial, or SONET/SDH
  2. service MTUs are set in the appropriate config>service context
  3. path MTUs are set with the path-mtu command under the config>service>sdp context
Figure 8:  MTU Points on the 7705 SAR 

Frame size configuration is supported for an Ethernet port configured as an access or a network port.

For an Ethernet adapter card that does not support jumbo frames, all frames received at an ingress network or access port are policed against 1576 bytes (1572 + 4 bytes of FCS), regardless of the port MTU. Any frames longer than 1576 bytes are discarded and the “Too Long Frame” and “Error Stats” counters in the port statistics display are incremented. See Jumbo Frames for more information.

At network egress, Ethernet frames are policed against the configured port MTU. If the frame exceeds the configured port MTU, the “Interface Out Discards” counter in the port statistics is incremented.

When the network group encryption (NGE) feature is used, additional bytes due to NGE packet overhead must be considered. Refer to the “NGE Packet Overhead and MTU Considerations” section in the 7705 SAR Services Guide for more information.

3.2.12.2. IP Fragmentation

IP fragmentation is used to fragment a packet that is larger than the MTU of the egress interface, so that the packet can be transported over that interface.

For IPv4, the router fragments or discards the IP packets based on whether the DF (Do not fragment) bit is set in the IP header. If the packet that exceeds the MTU cannot be fragmented, the packet is discarded and an ICMP message “Fragmentation Needed and Don’t Fragment was Set” is sent back to the source IP address.

For IPv6, the router cannot fragment the packet so must discard it. An ICMP message “Packet too big” is sent back to the source node.

As a source of self-generated traffic, the 7705 SAR can perform packet fragmentation.

Fragmentation can be enabled for GRE tunnels. Refer to the “GRE Fragmentation” section in the 7705 SAR Services Guide for more information.

3.2.12.3. Jumbo Frames

Jumbo frames are supported on Ethernet ports except on the 8-port Ethernet Adapter card (version 1).

The maximum MTU size for a jumbo frame on the 7705 SAR is 9732 bytes. The maximum MTU for a jumbo frame may vary depending on the Ethernet encapsulation type, as shown in Table 11. The calculations of the other MTU values (service MTU, path MTU, and so on) are based on the port MTU. The values in Table 11 are also maximum receive unit (MRU) values. MTU values are user-configured values. MRU values are the maximum MTU value that a user can configure on an adapter card that supports jumbo frames.

Table 11:  Maximum MTU (or MRU) per Ethernet Encapsulation Type  

Encapsulation

Maximum MTU (bytes)

Null

9724

Dot1q

9728

QinQ

9732

For an Ethernet Adapter card, all frames received at an ingress network or access port are policed against the MRU for the ingress adapter card, regardless of the configured MTU. Any frames larger than the MRU are discarded and the “Too Long Frame” and “Error Stats” counters in the port statistics display are incremented.

At network egress, frames are checked against the configured port MTU. If the frame exceeds the configured port MTU and the DF bit is set, then the “MTU Exceeded” discard counter will be incremented on the ingress IP interface statistics display, or on the MPLS interface statistics display if the packet is an MPLS packet.

For example, on adapter cards that do not support an MTU greater than 2106 bytes, fragmentation is not supported for frames greater than the maximum supported MTU for that card (that is, 2106 bytes). If the maximum supported MTU is exceeded, the following occurs.

  1. An appropriate ICMP reply message (Destination Unreachable) is generated by the 7705 SAR. The router ensures that the ICMP generated message cannot be used as a DOS attack (that is, the router paces the ICMP message).
  2. The appropriate statistics are incremented.

Jumbo frames offer better utilization of an Ethernet link because as more payload is packed into an Ethernet frame of constant size, the ratio of overhead to payload is minimized.

From the traffic management perspective, large payloads may cause long delays, so a balance between link utilization and delay must be found. For example, for ATM VLLs, concatenating a large number of ATM cells when the MTU is set to a very high value could generate a 9-kbyte ATM VLL frame. Transmitting a frame that large would take more than 23 ms on a 3-Mb/s policed Ethernet uplink.

3.2.12.3.1. Behavior of Adapter Cards Not Supporting Jumbo Frames on 7705 SAR-8 and 7705 SAR-18 only

The 7705 SAR-8 (with CSMv2) and the 7705 SAR-18 do not support ingress fragmentation, and this is true for jumbo frames. Therefore, any jumbo frame packet arriving on one of these routers that gets routed to an adapter card that does not support jumbo frame MTU (for example, a 16-port T1/E1 ASAP Adapter card or a 4-port OC3/STM1 / 1-port OC12/STM4 Adapter card) is discarded if the packet size is greater than the TDM port’s maximum supported MTU. If the maximum-supported MTU is exceeded, the following occurs.

  1. An appropriate ICMP reply message (Destination Unreachable) is generated by the 7705 SAR. The router ensures that the ICMP-generated message cannot be used as a DOS attack (that is, the router paces the ICMP message).
  2. The port statistics show IP or MPLS Interface MTU discards, for IP or MPLS traffic, respectively. MTU Exceeded Packets and Bytes counters exist separately for IPv4/6 and MPLS under the IP interface hierarchy for all discarded packets where ICMP Error messages are not generated.

For example, if a packet arrives on an 8-port Gigabit Ethernet Adapter card and is to be forwarded to a 16-port T1/E1 ASAP Adapter card with a maximum port MTU of 2090 bytes and a channel group configured for PPP with the port MTU of 1000 bytes, the following may occur.

  1. If the arriving packet is 800 bytes, then forward the packet.
  2. If the arriving packet is 1400 bytes, then forward the packet, which will be fragmented by the egress adapter card.
  3. If the arriving packet is fragmented and the fragments are 800 bytes, then forward the packet.
  4. If the arriving packet is 2500 bytes, then send an ICMP error message (because the egress adapter card has a maximum port MTU of 2090 bytes).
  5. If the arriving packet is fragmented and the fragment size is 2500 bytes, then there is an ICMP error.

3.2.12.3.2. Jumbo Frame Behavior on the Fixed Platforms

The 7705 SAR-A, 7705 SAR-Ax, 7705 SAR-H, 7705 SAR-Hc, 7705 SAR-M, 7705 SAR-W, 7705 SAR-Wx, and 7705 SAR-X are able to fragment packets between Ethernet ports (which support jumbo frames) and TDM ports (which do not support jumbo frames). In this case, when a packet arrives from a port that supports jumbo frames and is routed to a port that does not support jumbo frames (that is, a TDM port) the packet will get fragmented to the port MTU of the TDM port.

For example, if a packet arrives on a 7705 SAR-A and is to be forwarded to a TDM port that has a maximum port MTU of 2090 bytes and a channel group configured for PPP with the port MTU of 1000 bytes (PPP port MTU), the following may occur.

  1. If the arriving packet is 800 bytes, then forward the packet.
  2. If the arriving packet is 1400 bytes and the DF bit is 0, then forward the packet, which will be fragmented to the PPP port MTU size.
  3. If the arriving packet is 2500 bytes and the DF bit is 0, then forward the packet, which will be fragmented to the PPP port MTU size.

3.2.12.3.3. Multicast Support for Jumbo Frames

Jumbo frames are supported in a multicast configuration as long as all adapter cards in the multicast group support jumbo frames. If an adapter card that does not support jumbo frames is present in the multicast group, the replicated multicast jumbo frame packet will be discarded by the fabric because of an MRU error of the fabric port (Rx).

The multicast group replicates the jumbo frame for all adapter cards, regardless of whether they support jumbo frames, only when forwarding the packet through the fabric. The replicated jumbo frame packet is discarded on adapter cards that do not support jumbo frames.

3.2.12.3.4. PMC Jumbo Frame Support

For the Packet Microwave Adapter card (PMC), ensure that the microwave hardware installed with the card supports the corresponding jumbo frame MTU. If the microwave hardware does not support the jumbo frame MTU, it is recommended that the MTU of the PMC port be set to the maximum frame size that is supported by the microwave hardware.

3.2.12.4. Default Port MTU Values

Table 12 displays the default and maximum port MTU values that are dependent upon the port type, mode, and encapsulation type.

Note:

The 7705 SAR now supports a lower IP MTU value of 128 bytes (from the original 512-byte minimum). The IP MTU is derived from the port MTU configuration for network ports. This lower IP MTU is supported only on Ethernet encapsulated ports. Refer to the 7705 SAR Services Guide, “Bandwidth Optimization for Low-speed Links” for information.

Table 12:  Port MTU Default and Maximum Values  

Port Type

Mode

Encap Type

Default (bytes)

Max MTU (bytes)

10/100 Ethernet 1

Access/ Network

null

1514

9724 2

dot1q

1518

9728 2

qinq 3

1522 (access only)

9732 (access only) 2

GigE SFP 1 and 10-GigE SFP+

Access/ Network

null

1514 (access)

1572 (network)

9724 (access and network)

dot1q

1518 (access)

1572 (network)

9728 (access and network)

qinq 3

1522 (access only)

9732 (access only)

Ring port

Network

null

9728 (fixed)

9728 (fixed)

v-port (on Ring adapter card)

Network

null

1572

9724

dot1q

1572

9728

DSL: SHDSL bonding (7705 SAR-M)

Access/ Network

null

1514 (access)

1572 (network)

2044

dot1q

1518 (access)

1572 (network)

2048

DSL: xDSL bonding (7705 SAR-M)

Access/ Network

null

1514 (access)

1572 (network)

1996

dot1q

1518 (access)

1572 (network)

2000

DSL: xDSL bonding (7705 SAR-Wx)

Access/ Network

null

1514 (access)

1572 (network)

1996

dot1q

1518 (access)

1572 (network)

2000

qinq 3

1522 (access only)

2000 (access only)

GPON

Access/ Network

null

1514 (access)

1572 (network)

2000

dot1q

1518 (access)

1572 (network)

2000

TDM (PW)

Access

cem

1514

1514

TDM (ATM PW)

Access

atm

1524

1524

TDM (FR PW)

Access

frame-relay

1514

2090

TDM (HDLC PW)

Access

hdlc

1514

2090

TDM (IW PW)

Access

cisco-hdlc

1514

2090

TDM (PPP/MLPPP)

Access

ipcp

1502

2090

Network

ppp-auto

1572

2090

Serial V.35 or X.21 4 (FR PW)

Access

frame-relay

1514

2090

Serial V.35 or X.21 4 (HDLC PW)

Access

hdlc

1514

2090

Serial V.35 or X.21 4 (IW PW)

Access

frame-relay

1514

2090

ipcp

1502

2090

cisco-hdlc

1514

2090

SONET/SDH

Access

atm

1524

1524

SONET/SDH

Network

ppp-auto

1572

2090

    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.
  4. For X.21 serial ports at super-rate speeds.

For more information, refer to the “MTU Settings” section in the 7705 SAR Services Guide.

3.2.13. LAG

This section contains information on the following topics:

3.2.13.1. LAG Overview

The 7705 SAR supports Link Aggregation Groups (LAGs) based on the IEEE 802.1ax standard (formerly 802.3ad). Link aggregation provides:

  1. increased bandwidth by combining multiple links into one logical link (in active/active mode)
  2. load sharing by distributing traffic across multiple links (in active/active mode)
  3. redundancy and increased resiliency between devices by having a standby link to act as backup if the active link fails (in active/standby mode)

In the 7705 SAR implementation, all links must operate at the same speed.

Packet sequencing must be maintained for any given session. The hashing algorithm deployed by Nokia routers is based on the type of traffic transported to ensure that all traffic in a flow remains in sequence while providing effective load sharing across the links in the LAG. See LAG and ECMP Hashing for more information.

LAGs must be statically configured or formed dynamically with Link Aggregation Control Protocol (LACP). See LACP and Active/Standby Operation for information on LACP.

All Ethernet-based supported services can benefit from LAG, including:

  1. network interfaces and SDPs
  2. spoke SDPs, mesh SDPs, and EVPN endpoints
  3. IES and VPRN interfaces and SAPs
  4. Ethernet and IP pseudowire SAPs
  5. routed VPLS (r-VPLS) SAPs

LAGs are supported on access, network, and hybrid ports. A LAG can be in active/active mode or in active/standby mode for access, network, or hybrid ports. Active/standby mode is a subset of active/active mode if subgroups are enabled.

LAGs are supported on access ports on the following:

  1. 8-port Ethernet Adapter card, version 2
  2. 8-port Gigabit Ethernet Adapter card
  3. 10-port 1GigE/1-port 10GigE X-Adapter card (10-port GigE mode)
  4. 6-port Ethernet 10Gbps Adapter card
  5. 4-port SAR-H Fast Ethernet module
  6. 6-port SAR-M Ethernet module
  7. Packet Microwave Adapter card (for ports not in a microwave link)
  8. all fixed platforms

LAGs are supported on network ports on the following:

  1. 8-port Ethernet Adapter card, version 2
  2. 8-port Gigabit Ethernet Adapter card
  3. 10-port 1GigE/1-port 10GigE X-Adapter card
  4. 6-port Ethernet 10Gbps Adapter card
  5. 4-port SAR-H Fast Ethernet module
  6. 6-port SAR-M Ethernet module
  7. Packet Microwave Adapter card (for ports not in a microwave link and ports in a 1+0 network microwave link; LAGs are not supported on ports in a 1+1 HSB microwave link)
  8. all fixed platforms

LAGs are supported on hybrid ports on the following:

  1. 8-port Gigabit Ethernet Adapter card
  2. 10-port 1GigE/1-port 10GigE X-Adapter card (10-port GigE mode)
  3. 6-port Ethernet 10Gbps Adapter card
  4. 6-port SAR-M Ethernet module
  5. Packet Microwave Adapter card (for ports not in a microwave link)
  6. all fixed platforms

On access ports, a LAG supports active/active and active/standby operation. For active/standby operation the links must be in different subgroups. Links can be on the same platform or adapter card/module or distributed over multiple components. Load sharing is supported among the active links in a LAG group.

On network ports, a LAG supports active/active and active/standby operation. For active/standby operation the links must be in different subgroups. Links can be on the same platform or adapter card/module or distributed over multiple components. Load sharing is supported among the active links in a LAG group. Any tunnel type (for example, IP, GRE, or MPLS) transporting any service type, any IP traffic, or any labeled traffic (LER, LSR) can use the LAG load-sharing, active/active, and active/standby functionality.

LAGs are supported on network 1+0 microwave links. Ports that are in a microwave link can be added to the same LAG as ports that are not in a microwave link. Ports belonging to a microwave link must have limited autonegotiation enabled before the link can be added to a LAG.

A LAG that contains ports in a microwave link must have LACP enabled for active/standby operation. Static LAG configuration (without LACP) is not supported for active/standby LAGs with microwave-enabled ports.

On hybrid ports, a LAG supports active/active and active/standby operation. For active/standby operation the links must be in different subgroups. Links can be on the same platform or adapter card/module or distributed over multiple components. Load sharing is supported among the active links in a LAG group.

A LAG group with assigned members can be converted from one mode to another as long as the number of member ports are supported in the new mode and the ports all support the new mode, none of the members belong to a microwave link, and the LAG group is not associated with a network interface or a SAP.

Note:

For details on LAG scale per platform or adapter card, contact your Nokia Technical support representative.

A subgroup is a group of links within a LAG. On access, network, or hybrid ports, a LAG can have a maximum of four subgroups and a subgroup can have links up to the maximum number supported on the LAG. The LAG is active/active if there is only one sub-group and is active/standby if there is more than one subgroup.

When configuring a LAG, most port features (port commands) can only be configured on the primary member port. The configuration, or any change to the configuration, is automatically propagated to any remaining ports within the same LAG. Operators cannot modify the configurations on non-primary ports. For more information, see Configuring LAG Parameters.

If the LAG has one member link on a first- or second-generation (Gen-1 or Gen-2) Ethernet adapter card, and the other link on a third-generation (Gen-3) Ethernet adapter card or platform, a mix-and-match scenario exists for traffic management on the LAG SAP. In this case, all QoS parameters for the LAG SAP are configured but only those parameters applicable to the active member link are used. See LAG Support on Mixed-Generation Hardware for more information.

Configuring a multiservice site (MSS) aggregate rate can restrict the use of LAG SAPs. For more information, refer to the “MSS and LAG Interaction on the 7705 SAR-8 and 7705 SAR-18” section in the 7705 SAR Quality of Service Guide.

3.2.13.2. LACP and Active/Standby Operation

On access, network, and hybrid ports, where multiple links in a LAG can be active at the same time, normal operation is that all non-failing links are active and traffic is load-balanced across all the active links. In some cases, however, it is desirable to have only some of the links active and the other links kept in standby mode. The Link Aggregation Control Protocol (LACP) is used to make the selection of the active links in a LAG predictable and compatible with any vendor equipment. The mechanism is based on the IEEE 802.1ax standard so that interoperability is ensured.

Note:

LACP cannot be configured for static LAG. For more information on static LAG, see Static LAG (Active/Standby LAG Operation without LACP).

LACP is disabled by default and therefore must be enabled on the LAG if required. LACP can be used in either active mode or passive mode. The mode must match with connected CE devices for proper operation. For example, if the LAG on the 7705 SAR end is configured to be active, the CE end must be passive.

Figure 9 shows the interconnection between a DSLAM and a LAG aggregation node. In this configuration, LAG is used to protect against hardware failure. If the active link goes down, the link on standby takes over (see Figure 10). The links are distributed across two different adapter cards to eliminate a single point of failure.

Figure 9:  LAG on Access Interconnection 
Figure 10:  LAG on Access Failure Switchover 

LACP handles active/standby operation of LAG subgroups as follows.

  1. Each link in a LAG is assigned to a subgroup. On access, network, and hybrid ports, a LAG can have a maximum of four subgroups and a subgroup can have up to the maximum number of links supported for the LAG. The selection algorithm implemented by LACP ensures that only one subgroup in a LAG is selected as active.
  2. The algorithm selects the active link as follows.
    1. If multiple subgroups satisfy the selection criteria, the subgroup currently active remains active. Initially, the subgroup containing the highest-priority (lowest value) eligible link is selected as active.
    2. An eligible member is a link that can potentially become active. This means it is operationally up, and if the slave-to-partner flag is set, the remote system did not disable its use (by signaling standby).
  3. The selection algorithm works in a revertive mode (for details, refer to the IEEE 802.1ax standard). This means that every time the configuration or status of a subgroup changes, the selection algorithm reruns. If multiple subgroups satisfy the selection criteria, the subgroup currently active remains active. This behavior does not apply if the selection-criteria hold-time parameter is set to infinite.

Log events and traps are generated at both the LAG and link level to indicate any LACP changes. See the TIMETRA-LAG-MIB for details.

3.2.13.3. QoS Adaptation for LAG on Access

QoS on access port LAGs (access ports and hybrid ports in access mode) is handled differently from QoS on network port LAGs. Based on the configured hashing, traffic on a SAP can be sent over multiple LAG ports or can use a single port of a LAG. There are two user-selectable adaptive QoS modes (distribute and link) that allow the user to determine how the configured QoS rate is distributed to each of the active LAG port SAP queue schedulers, SAP schedulers (H-QoS), and MSS schedulers. These modes are:

  1. adapt-qos distribute
    For SAP queue schedulers, SAP schedulers (H-QoS), and SAP egress MSS schedulers, distribute mode divides the QoS rates (as specified by the SLA) equally among the active LAG links (ports). For example, if a SAP queue PIR and CIR are configured on an active/active LAG SAP to be 200 Mb/s and 100 Mb/s respectively, and there are four active LAG ports, the SAP queue on each LAG port will be configured with a PIR of 50 Mb/s (200/4) and a CIR of 25 Mb/s (100/4).
    For the SAP ingress MSS scheduler, the scheduler rate is configured on an MDA basis. Distributive adaptive QoS divides the QoS rates (as specified by the SLA) among the active link MDAs proportionally to the number of active links on each MDA. For example, if an MSS shaper group with an aggregate rate of 200 Mb/s and a CIR of 100 Mb/s is assigned to an active/active LAG SAP where the LAG has two ports on MDA 1 and three ports on MDA 2, the MSS shaper group on MDA 1 will have an aggregate rate of 80 Mb/s (200 × 2/5 of the SLA) and a CIR of 40 Mb/s (100 × 2/5 of the SLA). MDA 2 will have an aggregate rate of 120 Mb/s (200 × 3/5) and a CIR of 60 Mb/s (100 × 3/5).
  2. adapt-qos link (default)
    For SAP queue schedulers, SAP schedulers (H-QoS), and SAP egress MSS schedulers, link mode forces the full QoS rates (as specified by the SLA) to be configured on each of the active LAG links. For example, if a SAP queue PIR and CIR are configured on an active/active LAG SAP to be 200 Mb/s and 100 Mb/s respectively, and there are two active LAG ports, the SAP queue on each LAG port will be configured to the full SLA, which is a PIR of 200 Mb/s and a CIR of 100 Mb/s.
    For the SAP ingress MSS scheduler, the scheduler rate is configured on an MDA basis. In LAG link mode, each active LAG link MDA MSS shaper scheduler is configured with the full SLA. For example, if an MSS shaper group is configured with an aggregate rate of 200 Mb/s and CIR of 100 Mb/s and is assigned to an active/active LAG SAP with three ports on MDA 1 and two ports on MDA 2, the MSS shaper group on MDA 1 and MDA 2 are each configured with the full SLA of 200 Mb/s for the aggregate rate and 100 Mb/s for the CIR.

Table 13 shows examples of rate and bandwidth distributions based on the adapt-qos mode configuration.

Table 13:  Adaptive QoS Rate and Bandwidth Distribution  

Distribute

Link

SAP queue scheduler

Rate distributed = rate / number of active links

100% rate configured on each LAG SAP queue

SAP scheduler (H-QoS)

Rate distributed = rate / number of active links

100% rate configured on each SAP scheduler

SAP egress MSS scheduler

Rate distributed = rate / number of active links

100% rate configured on each port’s MSS scheduler

SAP ingress MSS scheduler

Rate distributed per active LAG MDA = rate × (number of active links on MDA / total number of active links)

100% rate configured on each active LAG MDA MSS scheduler

The following restrictions apply to ingress MSS LAG adaptive QoS (distribute mode).

  1. A unique MSS shaper group must be used per LAG when a non-default ingress MSS shaper group is assigned to a LAG SAP using adaptive QoS.
  2. When a shaper group is assigned to a LAG SAP using adaptive QoS, all ports in the LAG group must have their MDAs assigned to the same shaper policy.

The following restrictions apply to egress MSS LAG.

  1. The shaper policy for all LAG ports in a LAG must be the same and can only be configured on the primary LAG port member.

The following limitations apply to adaptive QoS (distribute mode).

  1. The QoS rates for an ingress LAG using adaptive QoS are only distributed among the active links when a non-default shaper group is used. If a default shaper group is used, the full QoS rates are configured for each port in the LAG as if link mode is being used.
  2. The QoS rates for an ingress or egress LAG using adaptive QoS will not be distributed among the active links when a user sets the PIR/CIR on a SAP queue, or aggregate rate/CIR on a SAP scheduler or MSS scheduler, to the default values (max and 0).
  3. A port on an 8-port Ethernet Adapter card, version 2, can be added to a LAG group but does not support H-QoS or MSS. If distributed mode is applied to a LAG SAP with a port on an 8-port Ethernet Adapter card, version 2, the H-QoS and MSS bandwidth distribution is determined based on all active links including the 8-port Ethernet Adapter card, version 2 port. However, the H-QoS or MSS bandwidth share for this port cannot be configured. Ports on other adapter cards, modules, or platforms will have their H-QoS or MSS bandwidth share configured.

3.2.13.3.1. Adaptive QoS Examples (Distribute Mode)

The following examples can be used as guidelines for configuring adapt-qos distribute.

SLA distribution for SAP queue-level PIR/CIR configuration

  1. Configure a qos sap-ingress policy with a queue ID of 2, a PIR of 200 Mb/s, and a CIR of 100 Mb/s. Assign it to an active/active LAG SAP with five active ports.
  2. For each port, the PIR/CIR configuration of SAP queue 2 is calculated so that the PIR = 40 Mb/s and CIR = 20 Mb/s.
  3. If one link goes down, the PIR/CIR configuration of SAP queue 2 on each active port is recalculated so that the PIR = 50 Mb/s and CIR = 25 Mb/s.

SLA distribution for ingress/egress (H-QoS)

  1. Create a LAG SAP with two different ports (for example, port 1/1/1 and port 1/1/2) in a LAG subgroup.
  2. Configure a LAG SAP aggregate rate of 200 Mb/s and a CIR of 100 Mb/s.
  3. To maintain the SLA, the SAP aggregate rate and CIR must be divided by the number of operational links in the LAG group.
  4. Because there are two active ports (links) in this LAG, the H-QoS aggregate rate and CIR are divided evenly between the two ports.
  5. The port 1/1/1 SAP scheduler (H-QoS) aggregate rate is 100 Mb/s and the CIR is 50 Mb/s.
  6. The port 1/1/2 SAP scheduler (H-QoS) aggregate rate is 100 Mb/s and the CIR is 50 Mb/s.

SLA distribution for Ingress MSS

  1. Configure a shaper group with an ID of 2 with an aggregate rate of 200 Mb/s and a CIR of 100 Mb/s.
  2. Create a LAG SAP using shaper group 2 that has two ports from one MDA (for example, ports 1/1/1 and 1/1/2) and three ports from a different MDA (for example, ports 1/2/1, 1/2/2, and 1/2/3) in its LAG group.
  3. The ingress MSS scheduler rate is configured on an MDA basis. Adaptive QoS divides the QoS rates among the active link MDAs, proportionally to the number of active links on each MDA.
  4. For MDA 1, the MSS shaper group aggregate rate is 80 Mb/s and the CIR is 40 Mb/s (2/5 of the bandwidth with two active links on MDA 1).
  5. For MDA 2, the MSS shaper group aggregate rate is 120 Mb/s and the CIR is 60 Mb/s (3/5 of the bandwidth with three active links on MDA 2).

3.2.13.4. Access Ingress Fabric Shaping

In order to avoid traffic congestion and ease the effects of possible bursts, a fabric shaper is implemented on each adapter card. Traffic being switched to a LAG SAP on an access interface goes through fabric shapers that are either in aggregate mode or destination mode. When in destination mode, the multipoint shaper is used to set the rate on all adapter cards. For more information on the modes used in fabric shaping, refer to the 7705 SAR Quality of Service Guide, “Configurable Ingress Shaping to Fabric (Access and Network)”.

Note:

Even though the multipoint shaper is used to set the fabric shaping rate for traffic switched to a LAG SAP, it is the per-destination unicast counters that are incremented to show the fabric statistics rather than the multipoint counter. Only the fabric statistics of the active port of the LAG are incremented, not the standby port.

3.2.13.5. Hold-down Timers

Hold-down timers control how quickly a LAG responds to operational port state changes. The following timers are supported:

  1. port-level hold-time (up/down) timer
    This timer controls the delay before a port is added to or removed from a LAG when the port comes up or goes down. Each port in the LAG has the same timer value, which is configured on the primary LAG link (port). The timer is set with the config>port>ethernet>hold-time command.
  2. subgroup-level hold-down timer
    This timer controls the delay before a switch from the current subgroup to a new candidate subgroup, selected by the LAG subgroup selection algorithm. The timer is set with the config>lag>selection-criteria command.
    The timer can be configured to never expire, which prevents a switch from an operationally up subgroup to a new candidate subgroup. This setting can be manually overridden by using the tools>perform>force>lag-id command (refer to the 7705 SAR OAM and Diagnostics Guide, “Tools Command Reference”, for information on this command).
    If the port-level timer is set, it must expire before the subgroup selection occurs and this timer is started. The subgroup-level timer is supported only for LAGs running LACP.
  3. LAG-level hold-down timer
    This timer controls the delay before a LAG is declared operationally down when the available links fall below the required port or bandwidth minimum. This timer is recommended for MC-LAG operation. The timer prevents a LAG from being brought down when an MC-LAG switchover executes a make-before-break switch. The LAG-level timer is set with the config>lag>hold-time down command.
    If the port-level timer is set, it must expire before the LAG operational status is processed and this timer is started.

3.2.13.6. Multi-Chassis LAG

Multi-chassis LAG (MC-LAG) is a redundancy feature on the 7705 SAR, useful for nodes that are taken out of service for maintenance, upgrades, or relocation. MC-LAG also provides redundancy for incidents of peer nodal failure. Refer to the “Multi-Chassis LAG Redundancy” section in the 7705 SAR Basic System Configuration Guide.

3.2.13.7. Static LAG (Active/Standby LAG Operation without LACP)

Some Layer 2 capable network equipment devices support LAG protected links in an active/standby mode but without LACP. This is commonly referred to as static LAG. In order to interwork with these products, the 7705 SAR supports configuring LAG without LACP.

LACP provides a standard means of communicating health and status information between LAG peers. If LACP is not used, the peers must be initially configured in a way that ensures that the ports on each end are connected and communicating. Otherwise, LAG will not be active. Which LAG peer is made active is a local decision. If the port priority settings are the same for all ports, it is possible that the two ends will select ports on different physical links and LAG will not be active. Decide the primary link by setting the port priority for the LAG on each peer to ensure that the active ports on each end coincide with the same physical link.

The key parameters for configuring static LAG are selection-criteria (set to best-port) and standby-signaling (set to power-off). The selection criteria is used to determine which selection algorithm decides the primary port (the active port in a no-fault condition). It is always the subgroup with the best-port (the highest-priority port - lowest configured value) that is chosen as the active subgroup. The selection criteria must be set to best-port before standby signaling can be placed in power-off mode. Once the selection criteria is set to best-port, setting the standby-signaling parameter to power-off causes the transmitters on the standby ports to be powered down.

After a switchover caused by a failure on the active link, the transmitters on the standby link are powered on. The switch time for static LAG is typically longer than it is with LACP, due to the time it takes for the transmitters to come up and transmission to be established. When the fault is restored, static LAG causes a revertive switch to take place. The revertive switch is of shorter duration than the initial switchover since the system is able to prepare the other side for the switch and initiate the switchover once it is ready.

Note:

Since the transmitters on the standby link are off, it is not possible for the LAG to respond to a physical disconnect (fault) on the standby link. This means that it is possible to have a failure on the active link result in a switch to a failed standby link.

3.2.13.8. LAG Support on Mixed-Generation Hardware

This section contains information on the following topics:

3.2.13.8.1. LAG Configuration at SAP Level

The 6-port Ethernet 10Gbps Adapter card and the 7705 SAR-X are third-generation (Gen-3) hardware components. All other Ethernet cards are second-generation (Gen-2) adapter cards, except the 8-port Ethernet Adapter card, which is a first-generation (Gen-1) adapter card. See Table 2 for a list of first-, second-, and third-generation Ethernet adapter cards, ports, and platforms.

The 7705 SAR supports mix-and-match traffic management (TM) across LAG members, where one member is a port on a Gen-3 adapter card or platform and the other member is a port on either a Gen-2 or Gen-1 adapter card or platform. Mix-and-match LAG does not apply to the 7705 SAR-X because it has only Gen-3 Ethernet ports.

For mix-and-match LAG TM scenarios, the 7705 SAR supports a generic QoS configuration, where the operator can configure all the settings available on each generation adapter card, but it is the card responsible for transporting traffic that determines which settings are applicable. That is, only the settings that apply to the active member port are used. The only exception is if there is a Gen-1 adapter card in the mix. In this case scheduling-mode cannot be changed to 16-priority scheduling. Only 4-priority scheduling is applicable.

For example, configuring scheduling-mode applies to Gen-2 adapter card SAPs but does not apply to the Gen-3 adapter card SAPs because Gen-3 cards support only one scheduling mode (4-priority), which is its implicit (default) scheduler mode and is not configurable. In another example, although per-SAP (second-tier) shaper rates can be configured for Gen-2 and Gen-3 cards, they will not be applied to Gen-1 cards.

Since it cannot be known whether SAP traffic rides over a Gen-2 or a Gen-3 adapter card and whether both adapter cards support H-QoS (tier 2, per-SAP shapers), the operator can choose to configure per-SAP aggregate CIR and PIR shaper rates. When the active link is on a Gen-2- or Gen-3-based port, per-SAP aggregate CIR and PIR rates are both used to enforce shaper rates, except when the active link is on a Gen-3-based port and traffic is in the network egress direction. In this case, only the PIR portion of the per-SAP aggregate rate is used to enforce shaper rates.

In the following descriptions of LAG configuration, scheduler-mode, agg-rate, and cir-rate refer to SAP configuration, as shown below for an Epipe SAP. Similar commands exist for SAPs in other services as well as for egress traffic.

Example:
config>service>epipe>sap lag-id>ingress#
   scheduler-mode {4-priority | 16-priority} 
   agg-rate-limit agg-rate [cir cir-rate] 
Note:

  1. The SAP identifier in the previous command has a lag-id (LAG SAP), not a port-id (regular SAP). A LAG SAP references two ports (one active and one standby), but only one port at a time carries traffic.
  2. The agg-rate is a PIR rate.

For information on traffic management for Gen-3 adapter cards and platforms, refer to the “QoS for Gen-3 Adapter Cards and Platforms” section in the 7705 SAR Quality of Service Guide.

For mix-and-match LAG configurations, the following behaviors apply.

  1. The configured aggregate rate on the LAG SAP is used to dictate the per-SAP aggregate rate on the active LAG port, regardless of which generation of adapter card is used (Gen-3 or Gen-2) or the configured scheduler mode. On a Gen-2 adapter card, the aggregate rate only applies when the port is in 16-priority scheduler mode. This behavior implies the following points.
    1. The scheduler mode can be set to 16-priority or 4-priority. When servicing packets, the Gen-2-based datapath uses the configured scheduler mode (16-priority or 4-priority), while the Gen-3-based datapath always uses 4-priority scheduling.
    2. When the traffic is transported over a Gen-3-based port (that is, the active link is on a Gen-3-based adapter card), the aggregate rate (agg-rate) is used to enforce a maximum shaper rate, as is the aggregate rate CIR (cir-rate).
    3. When the active link is on a Gen-2-based adapter card, both aggregate rate CIR and PIR (cir-rate and agg-rate) are used. The aggregate rate (PIR) enforces the per-SAP bandwidth limit, and the CIR is used to identify in-profile and out-of-profile packets for aggregate scheduling purposes.
    4. When the active link is on a Gen-1-based adapter card, aggregate rate CIR and PIR do not apply.

In addition, the following items describe mix-and-match LAG configuration behavior (that is, how the LAG SAP settings are applied or ignored depending on the active member port).

  1. For a LAG SAP, scheduler-mode, agg-rate, and cir-rate are all configurable on a per-SAP basis, regardless of the LAG member port combination (that is, both Gen-2 ports, both Gen-3 ports, or a Gen-2-/Gen-3 port mix).
  2. Scheduler-mode can be set to 4-priority or 16-priority, regardless of the LAG member port combination, except when one member is a port on a Gen-1 adapter card. In this case, only 4-priority scheduling is available.
  3. Agg-rate and cir-rate can be set whether scheduler-mode is set to 4-priority or 16-priority.
  4. The configured scheduler-mode applies to Gen-2-based LAG member ports only, and is not used for Gen-3-based LAG member ports. Gen-3 cards always use 4-priority scheduler mode and Gen-1 cards always use 4-priority scheduler mode. The unshaped-sap-cir keyword does not apply to Gen-3 SAPs because Gen-3 SAPs are all shaped SAPs.
  5. If scheduler-mode is 4-priority on the LAG SAP, where the LAG has one Gen-1-based or Gen-2-based port member and one Gen-3-based port member, the following points apply.
    1. The Gen-1-based or Gen-2-based adapter card is configured with 4-priority scheduling, while agg-rate and cir-rate are not applied, and H-QoS is not enabled.
    2. The Gen-3-based adapter card is configured with agg-rate and cir-rate, while scheduler-mode is ignored.
    3. When LAG active/standby switching occurs from an active Gen-3-based port to an active Gen-1-based or Gen-2-based port, traffic management is changed from a 4-priority scheduler with H-QoS to a 4-priority scheduler without H-QoS that behaves like an unshaped SAP.
    4. For the reverse case, when LAG active/standby switching occurs from an active Gen-1-based or Gen-2-based port to an active Gen-3-based port, traffic management is changed from a 4-priority scheduler without H-QoS to a 4-priority scheduler with H-QoS.
  6. If scheduler-mode is 16-priority on the LAG SAP, where the LAG has one Gen-2-based port member and one Gen-3-based port member, the following points apply.
    1. The Gen-2-based adapter card is configured with 16-priority scheduling mode, agg-rate and cir-rate. This means that H-QoS is enabled.
    2. The Gen-3-based adapter card is configured with agg-rate and cir-rate, while scheduler-mode is ignored.
    3. When LAG active/standby switching occurs from an active Gen-3-based port to an active Gen-2-based port, traffic management is changed from a 4-priority scheduler with H-QoS using the agg-rate and cir-rate, to a 16-priority scheduler with H-QoS using the agg-rate and the cir-rate (that is, from 4-priority (Gen-3) mode to 16-priority mode for shaped SAPs).
    4. For the reverse case, when LAG active/standby switching occurs from an active Gen-2-based port to an active Gen-3-based port, traffic management is changed from a 16-priority scheduler with H-QoS using the agg-rate and the cir-rate, to a 4-priority (Gen-3) scheduler with H-QoS enabled using the agg-rate and the cir-rate.
  7. If scheduler-mode is 16-priority mode on the LAG SAP, the combination of a Gen-1-based port with a Gen-2-based or Gen-3-based port is blocked because Gen-1 adapter cards do not support 16-priority mode. The only valid option for this combination of ports is 4-priority scheduling mode.

Lastly, for LAG on access ports, the primary port configuration settings are applied to both the primary and secondary LAG ports. Therefore, in order to support unshaped SAPs when the primary port is a Gen-3-based port and the secondary port is a Gen-2-based port, configuring the unshaped-sap-cir on the Gen-3-based port is allowed, even though it does not apply to the Gen-3-based port. This is because unshaped-sap-cir is needed by the secondary Gen-2-based port when it becomes the active port. The full command is config>port>ethernet>access>egress> unshaped-sap-cir cir-rate.

3.2.13.8.2. LAG Configuration at Port Level

The 7705 SAR allows all configurations on Gen-1, Gen-2, and Gen-3 ports, even if some or all of the configuration is not applicable to all the ports. The software uses only the settings that are applicable to the particular port and ignores those that are not applicable. Any change to the primary LAG member configuration propagates to all non-primary ports.

Table 14 lists the port commands that can be affected by LAG configuration, indicates the command’s applicability to Gen-1, Gen-2, and Gen-3 ports, and describes the LAG behavior for mixed LAG configuration.

Note:

For LAG on network ports, the egress-rate, unshaped-if-cir, and network-queue policy can only be configured on the primary LAG port and this configuration is propagated to the other LAG members.

Table 14:  Port Command Applicability for LAG Configurations on Mixed-Generation Hardware  

CLI Command

Gen-1 Port

Gen-2 Port

Gen-2 Port on Module 1

Gen-3 Port

Configuration Behavior

unshaped-if-cir

Supported 2

Supported 2

Supported 2

Supported 3

Allowed on Gen-1, Gen-2, and Gen-3 hardware, but not on Fast Ethernet ports. All port members of the same LAG must have the same value. 

unshaped-sap-cir

N/A

Supported

Supported

N/A

Allowed on Gen-2 and Gen-3 hardware, but not on Gen-1 hardware. This means LAGs with Gen-1 members and Gen-2 or Gen-3 members do not allow the unshaped-sap-cir command to be configured to a non-zero value on Gen-2 or Gen-3 ports. 

LAGs with Gen-2 and Gen-3 members are allowed if all member ports have the same unshaped-sap-cir value. Change the value only on the primary member. The value is propagated to all other members.

shaper-policy

N/A

Supported

Supported

Supported

Allowed on Gen-2 and Gen-3 hardware, but not on Gen-1 hardware. The same restrictions described above for the unshaped-sap-cir command for LAG members apply.

cbs

Supported

Supported

Supported

Supported

Allowed on all hardware generations. All LAG members must have the same value. Change the value only on the primary member. The value is propagated to all other members. 

src-pause

Enable or disable

Enable or disable

Disable

Enable or disable

Allowed to change enable/disable on Gen-1, Gen-2, and Gen-3 hardware, except for a Gen-3 port on a 6-port SAR-M Ethernet Module, where only the no src-pause command is supported and cannot be changed. All LAG members must have same value.  Change the value only on the primary member. The value is propagated to all other members. 

include-fcs

N/A

Enable or disable

Always enabled

Enable or disable

Allowed on Gen-2 and Gen-3 hardware, but not on Gen-1 hardware. The same restrictions described above for the unshaped-sap-cir command for LAG members apply.

scheduler-mode (for port)

Profile or 4-priority

16-priority

16-priority

4-priority

Allowed to configure per-port independently, whether the port is a standalone or an active/standby member. There is no propagation among ports within the same LAG.

    Notes:

  1. Refers to the 6-port SAR-M Ethernet module.
  2. Not supported on Fast Ethernet ports.
  3. If the port is in network mode, the unshaped-if-cir command can be configured but does not take effect. If the port is in hybrid mode, the command takes effect.

As indicated in Table 14, each generation of adapter card uses its own configured scheduler mode, or uses the only command option available for Gen-2 and Gen-3 adapter cards, whereas Gen-1 adapter cards use their own adapter card configuration. For example, on a LAG where:

  1. one member link is on Gen-2 hardware
    1. this port uses 16-priority scheduler mode, which is the default mode and cannot be changed
  2. one member link is on Gen-3 hardware
    1. this port uses 4-priority (Gen-3) scheduler mode, which is the default mode and cannot be changed
  3. one member link is on Gen-1 hardware
    1. this port uses its configured scheduler mode (profiled or 4-priority), which is dictated via the configuration applied to the port

3.2.14. LAG and ECMP Hashing

If it is necessary to increase the available bandwidth for a logical link that exceeds the physical bandwidth or to add redundancy for a physical link, typically one of two methods is applied: LAG or ECMP. A system can also deploy both at the same time using ECMP of two or more LAGs and/or single links.

The 7705 SAR supports per-flow and per-service hashing, as described in the following sections:

Note:

For general information on LAG, see LAG. For general information on ECMP, refer to the 7705 SAR Router Configuration Guide, “Static Routes, Dynamic Routes, and ECMP”.

3.2.14.1. Per-Flow Hashing

The 7705 SAR supports per-flow hashing for LAG and ECMP. Per-flow hashing uses information in a packet as an input to the hash function, ensuring that any given traffic flow maps to the same egress LAG port or ECMP path.

Depending on the type of traffic that needs to be distributed in an ECMP or LAG path, different variables are used as the input to the hashing algorithm that determines the selection of the next hop (ECMP) or port (LAG). The hashing result can be changed using the options described in Per-Service Hashing, LSR Hashing, Layer 4 Load Balancing, TEID Hashing for GTP-encapsulated Traffic, and Entropy Labels.

Table 15 summarizes the possible inputs to the hashing algorithm for ECMP and LAG.

Fragmented packets cannot use Layer 4 UDP/TCP ports or tunnel endpoint IDs (TEIDs). The datapath looks at IP source address and destination address only, even if configured to use Layer 4 UDP/TCP ports or TEID.

In Table 15, the hashing inputs in the Service ID column and the inputs in the other columns are mutually exclusive. Where checkmarks appear on both the per-service and per-flow sides of the table, refer to the table note in the Service ID column to determine when per-service hashing is used.

Table 15:  Hashing Algorithm Inputs (ECMP and LAG)  

Traffic Type

Per- Service

Per-Flow

Service ID

System IPv4 Address 1

Ingress Port  2

Source and Destination

TEID  4

Internal Multicast Group ID  5

MPLS Label Stack

Entropy Label

MAC Address

IP Address

UDP/TCP Port  3

ECMP

IPv4 routed

 6

IPv6 routed

 6

MPLS LSR

 7, 8

 9

 9

MPLS MVPN (LSR, eLER)

VPLS

Epipe

Apipe, Cpipe, Fpipe, Ipipe, Hpipe

LAG

IPv4 routed

IPv6 routed

MPLS LSR

 7, 8

 9

 9

MPLS MVPN (LSR, eLER)

VPLS

 10

Epipe

 10

Apipe, Cpipe, Fpipe, Ipipe, Hpipe

    Notes:

  1. The system IP address can be included as a hashing input for both IP and LDP ECMP using the system-ip-load-balancing command at the system level.
  2. Optional hashing input that is included when the use-ingress-port command is enabled.
  3. Optional hashing input that is included when the l4-load-balancing command is enabled (for IP ECMP) or when the hashing algorithm is configured as lbl-ip-l4-teid in the lsr-load-balancing command (for LDP ECMP). Layer 4 load balancing at the service level is not affected by Layer 4 load balancing at the system, router interface, or service interface levels (IES and VPRN).
  4. Optional hashing input that is included when the teid-load-balancing command is enabled (for IP ECMP) or when the hashing algorithm is configured as lbl-ip-l4-teid in the lsr-load-balancing command (for LDP ECMP). TEID load balancing at the service level is not affected by TEID load balancing at the router interface or service interface levels (IES and VPRN).
  5. Only applies to multicast traffic. The internal multicast group ID is generated from either the (S,G) record (IGMP snooping, MLD snooping, and PIM snooping), the point-to-multipoint label binding, or the VPLS service creation.
  6. Only for Layer 3 traffic going to a Layer 3 spoke SDP interface.
  7. Only included when the first nibble after the bottom of stack (BoS) bit is “4”, in which case the next header encapsulation is considered to be an IPv4 header.
  8. Optional hashing input that is included when LSR hashing is configured as label-ip.
  9. MPLS label stack and entropy label are mutually exclusive hashing inputs. When an entropy label indicator (ELI) and entropy label (EL) are found in the label stack, the MPLS labels are not used as hashing inputs.
  10. Optional hashing input that is included when the per-service-hashing command is enabled in a service (VPLS or Epipe). The default setting is disabled, which should be changed to enabled if pre-Release 8.0.R4 behavior is needed.

3.2.14.2. Per-Service Hashing

The 7705 SAR supports load balancing based on service ID, as shown in Table 15, The 7705 SAR uses the service ID as the input to the hash function. Per-service and per-flow hashing are mutually exclusive features.

For IPv4 and IPv6 routed traffic under ECMP operation, the service ID is used as the hashing input for Layer 3 traffic going to a Layer 3 spoke SDP interface. Otherwise, per-flow load balancing is used.

For Epipe and VPLS services under LAG operation, the per-service-hashing command and the l4-load-balancing and teid-load-balancing commands are mutually exclusive. Load balancing via per-service hashing is configured under the config>service> epipe>load-balancing and config>service>vpls> load-balancing contexts.

Note:

  1. Prior to Release 8.0.R4 of the 7705 SAR, load balancing for an Epipe service was implicitly defaulted to be enabled (that is, hashing was always on the service ID). Release 8.0.R4 adds the per-service-hashing command, which is disabled by default. The per-service-hashing command must be explicitly enabled if pre-Release 8.0.R4 behavior is needed.
  2. Starting with Release 8.0.R4, unless per-service-hashing is enabled, a 4-byte hash value will be appended to internal overhead for VPLS multicast traffic at ingress. The egress internal hash value is discarded at egress before scheduling. Therefore, shaping rates at access and network ingress and for fabric policies may need to be adjusted accordingly. In addition, the 4-byte internal hash value may be included in any affected statistics counters.
  3. Starting with Release 9.0.R4, support for multiple LSPs (RSVP-TE or segment routing TE (SR-TE)) in the same SDP is added as part of the mixed-LSP SDP feature (refer to the “Mixed-LSP SDPs” section in the 7705 SAR Services Guide for details). When an SDP is configured with multiple LSPs of the same type, it allows load balancing of the traffic in a similar manner as load-balancing for LDP ECMP, but only at the iLER point. Therefore, the per-flow hashing and per-service hashing behavior described in this section for LDP ECMP at the iLER also applies to multiple LSPs (RSVP-TE or SR-TE) in the same SDP.

3.2.14.3. LSR Hashing

LSR hashing operates on the label stack and can also include hashing on the IP header if the packet is an IPv4 packet. The label-IP hashing algorithm can also include the Layer 4 header and the TEID field. The default hash is on the label stack only. IPv4 is the only IP hashing supported on a 7705 SAR LSR.

When a 7705 SAR is acting as an LSR, it considers a packet to be IP if the first nibble following the bottom of the label stack is 4 (IPv4). This allows the user to include an IP header in the hashing routine at an LSR in order to spray labeled IP packets over multiple equal-cost paths in ECMP in an LDP LSP and/or over multiple links of a LAG group in all types of LSPs.

Other LSR hashing options include label stack profile options on the significance of the bottom-of-stack label (VC label), the inclusion or exclusion of the ingress port, and the inclusion or exclusion of the system IP address.

Note:

The global IF index is no longer a hash input for LSR ECMP load balancing. It has been replaced with the use-ingress-port configurable option in the lsr-load-balancing command. As well, the default treatment of the MPLS label stack has changed to focus on the bottom-of-stack label (VC label). In previous releases, all labels had equal influence.

LSR load balancing is configured using the config>system>lsr-load-balancing or config>router>if>lsr-load-balancing command. Configuration at the router interface level overrides the system-level configuration for the specified interface.

If an ELI is found in the label stack, the entropy label is used as the hash result. Hashing continues based on the configuration of label-only (lbl-only), label-IP (lbl-ip), or label-IP with Layer 4 header and TEID (lbl-ip-l4-teid) options.

3.2.14.3.1. LSR Label-only Hashing

ECMP operation consists of an initial hash based on the system IP address, then on the global port number if the use-ingress-port option is enabled.

Each label in the stack is then hashed separately with the result of the previous hash, up to a maximum of 16 labels. The net result is used to select which LDP FEC next hop to send the packet to using a threshold hashing operation of the net result with the number of next hops. Threshold hashing is described in RFC 2992, Analysis of an Equal-Cost Multi-Path Algorithm.

If an ELI is found in the label stack, the entropy label replaces the MPLS label stack hashing result and hashing continues.

If the selected LDP FEC or LSP has its NHLFE programmed with a LAG interface, a second round of hashing is needed, using the net result of the first round of hashing as the hashing input.

3.2.14.3.2. LSR Label-IP Hashing

In the first round of hashing for LSR label IP hashing, the algorithm parses down the label stack as described in LSR Label-only Hashing.

When the algorithm reaches the bottom of the stack, it checks the next nibble. If the nibble value is 4, the packet is assumed to be an IPv4 packet and the result of the label hash is fed into another hash along with the source and destination address fields in the IP packet header. If the nibble value is not 4, the algorithm will just use the label stack hash already calculated for the ECMP path selection.

The second round of hashing for LAG reuses the net result of the first round of hashing.

3.2.14.3.3. LSR Label-IP Hashing with Layer 4 Header and TEID

If the lbl-ip-l4-teid option is configured, the Layer 4 source and destination UDP or TCP port fields and the TEID field in the GTP header are included in the label-IP hashing calculation. See Layer 4 Load Balancing and TEID Hashing for GTP-encapsulated Traffic for more information.

3.2.14.3.4. Label Stack Profile Options

The lsr-load-balancing command includes a bottom-of-stack option that determines the significance of the bottom-of-stack label (VC label) based on which label stack profile option is specified. The profiles are:

  1. profile 1: favors better load balancing for pseudowires when the VC label distribution is contiguous (default)
  2. profile 2: similar to profile 1 where the VC labels are contiguous, but provides an alternate distribution
  3. profile 3: all labels have equal influence in hash key generation

3.2.14.3.5. Ingress Port

The use-ingress-port option, when enabled, specifies that the ingress port will be used by the hashing algorithm at the LSR. This option should be enabled for ingress LAG ports because packets with the same label stack can arrive on all ports of a LAG interface. In this case, using the ingress port in the hashing algorithm will result in better egress load balancing, especially for pseudowires.

The option should be disabled for LDP ECMP so that the ingress port is not used by the hashing algorithm. For ingress LDP ECMP, if the ingress port is used by the hashing algorithm, the hash distribution could be biased, especially for pseudowires.

3.2.14.4. Layer 4 Load Balancing

The IP Layer 4 load-balancing option includes the TCP/UDP source and destination port numbers in addition to the source and destination IP addresses in per-flow hashing of IP packets. By including the Layer 4 information, a source address/destination address default hash flow can be subdivided into multiple finer-granularity flows if the ports used between a source address and destination address vary.

Layer 4 load balancing is configured at the system level using the config>system>l4-load-balancing command. It can also be configured at the router interface level or the service interface level (IES and VPRN). Configuration at the router interface or service interface level overrides the system-level configuration for the specified interface or service.

For LSR LDP ECMP, Layer 4 load balancing is configured using the lbl-ip-l4-teid option in the lsr-load-balancing command at the system level or router interface level. Configuration at the router interface level overrides the system-level configuration for the specified interface.

Layer 4 load balancing can also be configured at the service level for Epipe and VPLS services. Layer 4 load balancing at the service level is not impacted by Layer 4 load balancing at the system, router interface, or service interface levels.

3.2.14.5. TEID Hashing for GTP-encapsulated Traffic

GTP is the GPRS (general packet radio service) tunneling protocol. The tunnel endpoint identifier (TEID) is a field in the GTP header. TEID hashing can be enabled on Layer 3 interfaces. The hash algorithm identifies the GTP-U protocol by checking the UDP destination port (2152) of an IP packet to be hashed. If the value of the port matches, the packet is assumed to be GTP-U. For GTPv1 packets, the TEID value from the expected header location is then included in the hash. For GTPv2 packets, the TEID flag value in the expected header is additionally checked to verify whether the TEID is present. If the TEID is present, it is included in the hash algorithm inputs.

TEID load balancing is configured at the router interface level using the config> router>if>teid-load-balancing command. It can also be configured at the IES or VPRN service interface level.

For LSR LDP ECMP, TEID load balancing is configured using the lbl-ip-l4-teid option in the lsr-load-balancing command at the system level or router interface level. Configuration at the router interface level overrides the system-level configuration for the specified interface.

TEID load balancing can also be configured at the service level for Epipe and VPLS services. TEID load balancing at the service level is not impacted by TEID load balancing at the router interface or service interface levels.

3.2.14.6. Entropy Labels

The 7705 SAR supports MPLS entropy labels on RSVP-TE and SR-TE LSPs, 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.

If an ELI is found in the label stack, the entropy label is used as the hash result and hashing continues based on the configuration of label-only (lbl-only) or label-IP (lbl-ip) options. For information on the behavior of LSR hashing when entropy label is enabled, see LSR Hashing.

To support entropy labels on RSVP-TE and SR-TE LSPs:

  1. the eLER must signal to the ingress node that entropy label capability (ELC) is enabled, meaning that the eLER can receive and process an entropy label for an LSP tunnel. Entropy labels are supported on RSVP-TE and SR-TE tunnels. Entropy labels are not supported on point-to-multipoint LSPs, BGP tunnels, or LDP FECs.
  2. the iLER must receive the entropy label capability signal and be configured to enable the insertion of entropy labels for the spoke SDP, mesh SDP, or EVPN endpoint. Inserting an entropy label adds two labels in the MPLS label stack: the entropy label itself and the ELI.

At the eLER, use the config>router>rsvp>entropy-label-capability command to enable entropy label capability on RSVP-TE LSPs.

At the iLER, use the entropy-label command to enable the insertion of the entropy label into the label stack. The command is found under the following services and protocols:

  1. Epipe and VPLS
    1. config>service>epipe>spoke-sdp
    2. config>service>epipe>bgp-evpn>mpls
    3. config>service>vpls>spoke-sdp
    4. config>service>vpls>mesh-sdp
    5. config>service>vpls>bgp-evpn>mpls
  2. IS-IS, OSPF, and MPLS
    1. config>router>isis>segment-routing
    2. config>router>ospf>segment-routing
    3. config>router>mpls

For details on entropy labels, refer to the “MPLS Entropy Labels” section in the 7705 SAR MPLS Guide.

3.2.14.7. Security Parameter Index (SPI) Load Balancing

SPI load balancing provides a mechanism to improve the hashing performance of IPSec encrypted traffic. IPSec-tunneled traffic transported over a LAG typically relies on IP header hashing only. For example, in LTE deployments, TEID hashing cannot be performed because of encryption, and the system performs IP-only tunnel-level hashing. Because each SPI in the IPSec header identifies a unique SA, and therefore a unique flow, these flows can be hashed individually without impacting packet ordering. In this way,

The 7705 SAR allows enabling SPI hashing per Layer 3 interface (this is the incoming interface for hash on system egress) or per Layer 2 VPLS service. When SPI hashing is enabled, an SPI value from the ESP/AH header is used in addition to any other IP hash input based on the per-flow hash configuration: source/destination IPv4/IPv6 addresses and Layer 4 source/destination ports in case NAT traversal is required and Layer 4 load balancing is enabled. If the ESP/AH header is not present in a packet received on a given interface, the SPI will not be part of the hash inputs and the packet is hashed as per other hashing configurations. SPI hashing is not used for fragmented traffic in order to ensure that first and subsequent fragments use the same hash inputs.

SPI hashing is supported for IPv4 and IPv6 tunnel unicast traffic.

3.2.15. SONET/SDH

This section contains information on the following topics:

The 7705 SAR supports SONET/SDH ports on the following adapter cards:

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

SONET/SDH ports can be clear channel (non-channelized) and channelized. The 4-port OC3/STM1 Clear Channel Adapter card supports only clear channel ports. The 2-port OC3/STM1 Channelized Adapter card supports channelized ports. The 4-port OC3/STM1 / 1-port OC12/STM4 Adapter card is a mixed-use adapter card that supports clear channel and channelized ports. The mda-mode command is used to configure the 4-port OC3/STM1 / 1-port OC12/STM4 Adapter card for 4-port or 1-port mode. See Configuring Cards for details.

Clear channel ports use the whole port—other than overhead bytes—as a single stream of bits. Channelized ports use various channel hierarchies to split the larger bandwidth into smaller channels, such as DS1, E1, DS3, or E3. Figure 11 and Figure 12 show the standards-based channel mapping for SONET and SDH, respectively. Channelized ports on the 2-port OC3/STM1 Channelized Adapter card and the 4-port OC3/STM1 / 1-port OC12/STM4 Adapter card support a subset of the standards-based mapping options, as shown in Table 16.

For SONET, the basic frame format unit is STS-1 (51.84 Mb/s), which is carried in the optical carrier level 1 (OC-1) signal, and three STS-1 frames can be carried in an STS-3 frame at the OC-3 level. For SDH, the basic frame format unit is STM-1 (155.52 Mb/s), which is carried in an OC-3 signal. SDH STM-1 using OC-3 and SONET STS-3 are functionally equivalent.

3.2.15.1. SONET

Figure 11 shows the SONET hierarchy at STS-12 (OC-12).

Figure 11:  SONET Hierarchy at STS-12  

A SONET multiplexing structure allows several combinations of signal transportation. For example, at the STS-3 (OC-3) level:

  1. STS-3 is achieved by interleaving three STS-1s byte by byte
  2. an STS-1 payload can be subdivided into virtual tributary groups (VTGs) and virtual tributaries (VTs). Each STS-1 may contain seven VTGs, which in turn carry sub-STS traffic in VTs. There are four VT sizes:
    1. VT1.5 (1.728 Mb/s) (typically used for DS1, indicated in the CLI as vt15)
    2. VT2 (2.304 Mb/s) (typically transports one E1)
    3. VT3 (3.456 Mb/s) (not shown in Figure 11)
    4. VT6 (6.912 Mb/s)
  3. each VTG can contain four VT1.5s, three VT2s, two VT3s, or one VT6
  4. each VTG can carry only VTs of the same size

3.2.15.2. SDH

Figure 12 shows the SDH hierarchy at STM-4 (OC-12).

Figure 12:  SDH Hierarchy at STM-4  

An SDH multiplexing structure allows several combinations of signal transportation. For example, at the STM-1 (OC-3) level:

  1. one STM-1 payload supports one administrative unit group (AUG)
  2. each AUG can contain either three administrative units (AU-3s) or a single AU-4

For example, the hierarchical possibilities for a single AU-4 are:

  1. each AU-4 transports data via a virtual container (VC-4)
  2. a VC-4 consists of three tributary unit groups (TUG-3s), where either:
    1. a single tributary unit (TU-3) can be multiplexed via a TUG-3, containing a VC-3 plus the VC-3 path overhead (POH) and TU-3 pointer
    2. seven TUG-2s can be multiplexed via a TUG-3, where each TUG-2 can contain one TU-2, three TU-12s, or four TU-11s
  3. the AU-4 structure addresses the data as (K, L, M), where K is the TUG-3 number, L is the TUG-2 number, and M is the TU-11/TU-12 number

3.2.15.3. SONET/SDH Path Support

The 7705 SAR supports a subset of the standards-based channel mapping options. Table 16 shows path support on the 7705 SAR.

Note:

When configuring a port for SDH framing, the 7705 SAR CLI uses SONET STS-n frame conventions. That is, SONET command syntax and nomenclature is used to configure both a SONET port and an SDH port.

The 7705 SAR CLI always uses the SONET VT frame convention. For example, the same SONET CLI syntax and nomenclature would be used to configure both a VT1.5 and a VC11. The framing {sonet | sdh} command determines whether VTs or VCs are being configured. Use the show>port-tree port-id command to display the SONET/SDH path containers.

Table 16:  SONET/SDH Paths Supported on the 7705 SAR  

Path Type

Port Framing

Path Configuration

2-port OC3/STM1 Channelized Adapter Card

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

4-port Mode

1-port Mode

OC3 clear channel

SDH

STM1>AUG1>VC4

Yes

OC3 clear channel

SONET

OC3>STS3>STS3c SPE

Yes

E1

SDH

STM1>AUG1>VC4>TUG3>TUG2>VC12

Yes

Yes

E1

SDH

STM1>AUG1>VC3>TUG2>VC12

Yes

Yes

E1

SDH

STM1>AUG1>VC4>TUG3>VC3>DS3

Yes

E1

SDH

STM1>AUG1>VC3>DS3

Yes

E1

SONET

OC3>STS1 SPE>DS3

Yes

DS1

SDH

STM1>AUG1>VC4>TUG3>TUG2>TU11>VC11

Yes

Yes

DS1

SDH

STM1>AUG1>VC3>TUG2>VC11

Yes

Yes

DS1

SDH

STM1>AUG1>VC4>TUG3>VC3>DS3

Yes

DS1

SDH

STM1>AUG1>VC3>DS3

Yes

DS1

SONET

OC3>STS1 SPE>VT GROUP>VT1.5 SPE

Yes

Yes

DS1

SONET

OC3>STS1 SPE>DS3

Yes

OC12 clear channel

SDH

STM4>AUG4>VC4-C4

Yes

OC12 clear channel

SONET

OC12>STS12>STS12c SPE

Yes

E1 using STS-3

SDH

STM4>AUG4>AUG1>VC4>TUG3>TUG2>VC12

Yes

E1 using STS-1

SDH

STM4>AUG4>AUG1>VC3>TUG2>VC12

Yes

DS1 using STS-3

SDH

STM4>AUG4>AUG1>VC4>TUG3>TUG2>TU11>VC11

Yes

DS1 using STS-1

SDH

STM4>AUG4>AUG1>VC3>TUG2>VC11

Yes

DS1 using STS-1

SONET

OC12>STS12>STS1 SPE >VT GROUP >VT1.5 SPE

Yes

3.2.15.3.1. SONET/SDH Channelized Port ID

When configuring a SONET/SDH port, users configure both SONET/SDH and TDM aspects of a channel. The CLI uses the sonet-sdh-index variable to identify a channel in order to match SONET/SDH parameters with TDM parameters for the channel.

A channelized port ID has one of the syntaxes shown in Table 17, as applicable to channelization and mapping options. In Table 17, the syntax contains port and path components, where the port is slot/mda/port and the path is the sonet-sdh-index. The sonet-sdh-index has one or more indexes (indicated by braces separated by a dot) and can have a high-level path label (indicated by bold text).

For example, in the highlighted row, port.sts1-{1 to 3} represents a SONET/SDH port divided into STS-1 (or STM-0) payloads identified as sts1-1, sts1-2, and sts1-3.

Table 17:  SONET/SDH Channelized Port Syntax Examples 

Port ID for Physical Port Speed

Channel Speed

OC12/STM4

OC3/STM1

DS3/E3

SONET/SDH

STS12/STM4

port.sts12

N/A

N/A

STS3/STM1

port.sts3-{1 to 4}

port.sts3

N/A

STS1/STM0

port.sts1-{1 to 4}.{1 to 3}

port.sts1-{1 to 3}

N/A

TUG3

port.tug3-{1 to 4}.{1 to 3}

port.tug3-{1 to 3}

N/A

TU3

N/A

port.tu3-{1 to 3}

N/A

VT1.5/VC1.1 1

port.vt15-{1 to 4}.{1 to 3}.{1 to 4}.{1 to 7}

port.vt15-{1 to 3}.{1 to 4}.{1 to 7}

N/A

VT2/VC12  1

port.vt2-{1 to 4}.{1 to 3}.{1 to 3}.{1 to 7}

port.vt2-{1 to 3}.{1 to 3}.{1 to 7}

N/A

TDM

DS3/E3

N/A

port.{1 to 3}

port

DS1 in DS3

N/A

port.{1 to 3}.{1 to 28}

port.{1 to 28}

DS1 in VT2

port.{1 to 4}.{1 to 3}.{1 to 3}.{1 to 7}

port.{1 to 3}.{1 to 3}.{1 to 7}

N/A

DS1 in VT1.5

port.{1 to 4}.{1 to 3}.{1 to 4}.{1 to 7}

port.{1 to 3}.{1 to 4}.{1 to 7}

N/A

E1 in DS3

N/A

port.{1 to 3}.{1 to 21}

port.{1 to 21}

E1 in VT2

port.{1 to 4}.{1 to 3}.{1 to 3}.{1 to 7}

port.{1 to 3}.{1 to 3}.{1 to 7}

N/A

N*DS0 in DS1 in DS3

N/A

port.{1 to 3}.{1 to 28}.{1 to 24}

port.{1 to 28}.{1 to 24}

N*DS0 in DS1 in VT2

port.{1 to 4}.{1 to 3}.{1 to 3}.{1 to 7}.{1 to 24}

port.{1 to 3}.{1 to 3}.{1 to 7}.{1 to 24}

N/A

N*DS0 in DS1 in VT1.5

port.{1 to 4}.{1 to 3}.{1 to 4}.{1 to 7}.{1 to 24}

port.{1 to 3}.{1 to 4}.{1 to 7}.{1 to 24}

N/A

N*DS0 in E1 in DS3

N/A

port.{1 to 3}.{1 to 21}.{2 to 32}

port.{1 to 21}.{2 to 32}

N*DS0 in E1 in VT2

port.{1 to 4}.{1 to 3}.{1 to 3}.{1 to 7}.{2 to 32}

port.{1 to 3}.{1 to 3}.{1 to 7}.{2 to 32}

N/A

    Note:

  1. Supported by TDM satellite.

3.2.16. Automatic Protection Switching

This section contains information on the following topics:

3.2.16.1. APS Overview

Automatic Protection Switching (APS) allows users to protect a SONET/SDH port or link with a backup (protection) facility of the same speed but from a different adapter card. APS provides protection against a port, signal, or adapter card failure. The 7705 SAR supports 1+1 APS protection in compliance with GR-253-CORE and ITU-T Recommendation G.841 to provide SONET/SDH carrier-grade reliability. All SONET/SDH paths and channels within a SONET/SDH port are protected.

When APS is enabled, the 7705 SAR constantly monitors the health of the APS links, APS ports, and APS-equipped adapter cards. If the signal on the active (working) port degrades or fails, the network proceeds through a predefined sequence of steps to transfer (or switch over) traffic processing to the protection port. This switchover is done very quickly to minimize traffic loss. Traffic is streamed from the protection port until the fault on the working port is cleared, at which time the traffic may optionally revert to the working port.

The 7705 SAR supports 1+1 single-chassis APS (SC-APS) and 1+1 multi-chassis APS (MC-APS). In an SC-APS group, both the working and protection circuit must be configured on the same node. In an MC-APS group, the working and protection circuits are configured on two separate nodes, providing protection from node failure in addition to protection from link and hardware failure.

Unidirectional and bidirectional modes are supported:

  1. unidirectional APS (Uni-1Plus1) — in unidirectional mode, only the port in the failed direction switches to the protection port. Unidirectional mode is supported only on SC-APS.
  2. bidirectional APS — in bidirectional mode, a failure in either direction causes both the near-end and far-end equipment to switch to the protection port in each direction. Bidirectional mode is the default mode and is supported on both SC-APS and MC-APS.

For SC-APS and MC-APS with MEF 8 services where the remote device performs source MAC validation, the MAC address of the channel group in each of the redundant interfaces may be configured to the same MAC address using the mac CLI command.

3.2.16.2. SC-APS

In an SC-APS group, both the working and protection circuits terminate on the same node. SC-APS is supported in unidirectional or bidirectional mode on:

  1. 2-port OC3/STM1 Channelized Adapter cards for TDM CES (Cpipes) and TDM CESoETH with MEF 8 with DS3/DS1/E1/DS0 channels
  2. 4-port OC3/STM1 / 1-port OC12/STM4 Adapter cards for MLPPP access ports or TDM CES (Cpipes) and TDM CESoETH (MEF 8) access ports with DS1/E1 channels, or on a network port configured for POS
  3. 4-port OC3/STM1 Clear Channel Adapter cards network side (configured for POS operation)

SC-APS with TDM access is supported on DS3, DS1, E1, and DS0 (64 kb/s) channels.

The working and protection circuits of an SC-APS group must be on two ports on different adapter cards.

Figure 13 shows an SC-APS group with physical port and adapter card failure protection. Figure 14 shows a packet network using SC-APS.

Figure 13:  SC-APS with Physical Port and Adapter Card Protection 
Figure 14:  SC-APS Application 

3.2.16.3. MC-APS

MC-APS extends the functionality offered by SC-APS to include protection against 7705 SAR node failure. MC-APS is supported in bidirectional mode on:

  1. 2-port OC3/STM1 Channelized Adapter cards for TDM CES (Cpipes) and TDM CESoETH with MEF 8 with DS3/DS1/E1/DS0 channels
  2. 4-port OC3/STM1 / 1-port OC12/STM4 Adapter cards for MLPPP access ports or CES (Cpipes) and TDM CESoETH (MEF 8) access ports with DS1/E1 channels

MC-APS with TDM access is supported on DS3, DS1, E1, and DS0 (64 kb/s) channels. TDM SAP-to-SAP with MC-APS is not supported.

With MC-APS, the working circuit of an APS group can be configured on one 7705 SAR node while the protection circuit of the same APS group is configured on a different 7705 SAR node. The working and protection nodes are connected by an IP link that establishes an MC-APS signaling path between the nodes.

The working and protection circuits must have compatible configurations, such as the same speed, framing, and port type. The circuits in an APS group on both the working and protection nodes must also have the same group ID, but they can have different port descriptions. In order for MC-APS to function correctly, pseudowire redundancy must be configured on both the working and protection circuits. For more information, refer to 7705 SAR Services Guide. MC-APS with pseudowire redundancy also supports Inter-Chassis Backup (ICB); see MC-APS and Inter-Chassis Backup for more information.

The working and protection nodes can be different platforms, such as a 7705 SAR-8 and a 7705 SAR-18. However, to prevent possible switchover performance issues, avoid mixing different platform types in the same MC-APS group. The 7705 SAR does not enforce configuration consistency between the working circuit and the protection circuit. Additionally, no service or network-specific configuration data is signaled or synchronized between the two routers.

An MC-APS signaling path is established using the IP link between the two routers by matching APS group IDs. A heartbeat protocol can also be used to add robustness. The signaling path verifies that one router is configured as the working circuit and the other is configured as the protection circuit. In case of a mismatch, an incompatible neighbor trap is generated. The protection router uses K1/K2 byte data, member circuit status, and the settings configured for the APS Tools Commands to select the working circuit. Changes in working circuit status are sent across the MC-APS signaling link from the working router to keep the protection router synchronized. External requests such as lockout, force, and manual switches are allowed only on the node with the protection circuit.

Figure 15 shows an MC-APS group with physical port, adapter card, and node protection. Figure 16 shows a packet network using MC-APS.

Figure 15:  MC-APS with Physical Port, Adapter Card and Node Protection 
Figure 16:  MC-APS Application 

3.2.16.3.1. MC-APS and Inter-Chassis Backup

Inter-Chassis Backup (ICB) spoke SDPs are supported for use with Cpipe services in an MC-APS 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 node to the protection node. Figure 17 shows an MC-APS group with pseudowire redundancy and ICB protection.

Figure 17:  MC-APS with Pseudowire Redundancy and ICB 

If the active link on the access side fails, an MC-APS switchover is triggered and a pseudowire switchover occurs. A failure on the network side triggers a pseudowire switchover but not an MC-APS switchover. For detailed information on pseudowire redundancy with ICB protection, refer to the 7705 SAR Services Guide, “PW Redundancy and Inter-Chassis Backup”.

3.2.16.4. K1 and K2 Bytes

The APS protocol uses the K1 and K2 bytes of the SONET/SDH header to exchange commands and replies between the near end and far end.

The switch priority of a request is assigned by bits 1 through 4 of the K1 byte, as shown in Table 18.

Table 18:  K1 Byte Switch Priorities  

Bits

Condition

1111

Lockout of Protection

1110

Forced Switch

1101

SF - High Priority (not used in 1+1 APS)

1100

SF - Low Priority

1011

SD - High Priority (not used in 1+1 APS)

1010

SD - Low Priority

1001

Not used

1000

Manual Switch

0111

Not used

0110

Wait-to-Restore

0101

Not used

0100

Exercise

0011

Not used

0010

Reverse Request

0001

Do Not Revert

0000

No Request

In unidirectional mode, the K1 and K2 bytes are not used to coordinate switch action; however, the K1 byte is still used to inform the other end of the local action, and bit 5 of the K2 byte is set to 0 to indicate 1+1 APS mode (see Table 19).

In bidirectional mode, the highest-priority local request is compared to the remote request (received from the far-end node using an APS command), and whichever request has the greater priority is selected. The requests can be automatically initiated (such as Signal Failure or Signal Degrade), external (such as Lockout, Forced Switch, Request Switch), or state requests (such as Revert-Time timers).

The channels requesting the switch action are assigned by bits 5 through 8. Only channel number codes 0 and 1 are supported on the 7705 SAR. If channel 0 is selected, the condition bits show the received protection channel status. If channel 1 is selected, the condition bits shows the received working channel status.

The K2 byte is used to indicate bridging actions performed at the line termination equipment (LTE), the provisioned architecture, and mode of operation, as shown in Table 19.

Table 19:  K2 Byte Functions  

Bits

Function

1 to 4

Channel number codes

5

0

Provisioned for 1+1 mode

1

Provisioned for 1:n mode

6 to 8

111

Line AIS

110

Line RDI

101

Provisioned for bidirectional switching

100

Provisioned for unidirectional switching

011

Reserved for future use

010

Reserved for future use

001

Reserved for future use

000

Reserved for future use

3.2.16.4.1. Bidirectional 1+1 APS example

Table 20 outlines the steps that the bidirectional APS process will go through during a typical automatic switching event. The example is read row by row, from left to right, to provide the complete process of the bidirectional switching event.

Table 20:  1+1 APS for Bidirectional Mode – Actions Taken 

Status

APS Commands Sent in K1 and K2 Bytes on Protection Line

Action

B to A

A to B

At Site B

At Site A

No failure (protection line is not in use)

“No request”

“No request”

No action

No action

Working line degraded in direction A to B

“SD” on working channel 1

“No request”

Failure detected, notify A and switch to protection line

No action

Site A receives SD failure condition

Same

“Reverse request”

No action

Remote failure detected, acknowledge and switch to protection line

Site B receives “Reverse request”

Same

Same

No action

No action

3.2.16.5. Revertive Mode

1+1 APS provides revertive and non-revertive modes; non-revertive mode is the default option. In revertive mode, the activity is switched back to the working port after the working line has recovered from a failure (or the manual switch is cleared). In non-revertive mode, a switch to the protection line is maintained even after the working line has recovered from a failure (or the manual switch is cleared).

To prevent frequent automatic switches that result from intermittent failures, a revert-time is defined for revertive switching. The revert-time is configurable from 0 to 60 min in increments of 1 min; the default value is 5 min. In some scenarios, performance issues can occur if the revert-time is set to 0; therefore, it is recommended that the revert-time always be set to a value of 1 or higher. Any change in the revert-time value takes effect upon the next initiation of the wait-to-restore (WTR) timer. The change does not modify the duration of a WTR timer that has already been started. The WTR timer of a non-revertive switch can be assumed to be infinite.

If both working and protection lines fail, the line that has less-severe errors will be active. If there is signal degradation on both ports, the active port that failed last will stay active. If there is signal failure on both ports, the working port will always be active because signal failure on the protection line is a higher priority than on the working line.

3.2.16.6. APS Tools Commands

3.2.16.6.1. Lockout Protection

The lockout protection command (tools>perform>aps>lockout) disables use of the protection line. Since the command has the highest priority, a failed working line using the protection line is switched back to itself even if it is in a fault condition. No switches to the protection line are allowed when the line is locked out. Refer to the 7705 SAR OAM and Diagnostics Guide, “Tools”, for information on the APS lockout command.

3.2.16.6.2. Request Switch of Active to Protection

The request or manual switch of active to protection command (tools>perform>aps> request) switches the active line to use the protection line (by issuing a manual switch request) unless a request of equal or higher priority is already in effect. If the active line is already on the protection line, no action takes place. Refer to the 7705 SAR OAM and Diagnostics Guide, “Tools”, for information on the APS request command.

3.2.16.6.3. Request Switch of Active to Working

The request or manual switch of active to working command (tools>perform>aps> request) switches the active line back from the protection line to the working line (by issuing a manual switch request) unless a request of equal or higher priority is already in effect. If the active line is already on the working line, no action takes place. Refer to the 7705 SAR OAM and Diagnostics Guide, “Tools”, for information on the APS request command.

3.2.16.6.4. Forced Switch from Working to Protection

The command tools>perform>aps>force>working forces an activity switch away from the working line to the protection line unless a request of equal or higher priority is already in effect. When the forced switch of working to protection command is in effect, it may be overridden either by a lockout command or by a signal fault on the protection line. If the active line is already on the protection line, no action takes place. Refer to the 7705 SAR OAM and Diagnostics Guide, “Tools”, for information on the APS force command.

3.2.16.6.5. Forced Switch from Protection to Working

The command tools>perform>aps>force>protect forces an activity switch away from the protection line and back to the working line unless a request of equal or higher priority is already in effect. Refer to the 7705 SAR OAM and Diagnostics Guide, “Tools”, for information on the APS force command.

3.2.16.6.6. Exercise

The exercise command (tools>perform>aps>exercise) is only supported in 1+1 APS bidirectional mode. The Exercise command exercises the protection line by sending an exercise request over the protection line to the far end and expecting a reverse request response back. The switch is not completed during the exercise routine. Refer to the 7705 SAR OAM and Diagnostics Guide, “Tools”, for information on the APS exercise command.

3.2.16.7. APS Failure Codes

3.2.16.7.1. Protection Switching Byte Failure (APS-PSB)

This failure indicates that the received K1 byte is either invalid or inconsistent. An invalid code defect occurs if the same K1 value is received for three consecutive frames and is either an unused code or irrelevant for the specific switching operation. An inconsistent code defect occurs when no 3 consecutive received K1 bytes of the last 12 frames are the same.

If the failure persists for 2.5 s, a Protection Switching Byte alarm is raised. When this failure is declared, the protection line is treated as if it were in the SF state. The received signal is then selected from the working line.

When the failure is absent for 10 s, the alarm is cleared and the SF state of the protection line is removed.

This alarm can only be raised by the active port operating in bidirectional mode.

3.2.16.7.2. Channel Mismatch Failure (APS-CM)

This failure indicates that there is a channel mismatch between the transmitted K1 bytes and the received K2 bytes. A defect is declared when the received K2 channel number differs from the transmitted K1 channel number for more than 50 ms after 3 identical K1 bytes are sent. The monitoring for this condition is continuous, not just when the transmitted value of K1 changes.

If the failure persists for 2.5 s, a Channel Mismatch Failure alarm is raised. When this failure is declared, the protection line is treated as if it were in the SF state. The received signal is then selected from the working line.

When the failure is absent for 10 s, the alarm is cleared and the SF state of the protection line is removed.

This alarm can only be raised by the active port operating in bidirectional mode.

3.2.16.7.3. APS Mode Mismatch Failure (APS-MM)

This failure can occur for two reasons. The first reason is that the received K2 byte indicates that 1:N protection switching is being used by the far end of the OC-N line, rather than 1+1 protection switching. The second reason is that the received K2 byte indicates that unidirectional mode is being used by the far end while the near end is using bidirectional mode. This defect is detected within 100 ms of receiving a K2 byte that indicates either of these conditions.

If the failure persists for 2.5 s, a Mode Mismatch Failure alarm is raised. When this failure is declared, if the defect indicates that the far end is configured for unidirectional mode, then the OC-N port reverts from its current bidirectional mode to unidirectional mode. However, the port continues to monitor the received K2 byte, and if the K2 byte indicates that the far end has switched to bidirectional mode, the OC-N port then reverts to bidirectional mode as well. The monitoring stops if the user explicitly reconfigures the local port to operate in unidirectional mode.

When the failure is absent for 10 s, the alarm is cleared, and the configured mode, which is 1+1 bidirectional, is used.

This alarm can only be raised by the active port operating in bidirectional mode.

3.2.16.7.4. Far-End Protection Line Failure (APS-FEPL)

This failure occurs when a K1 byte is received in three consecutive frames that indicates a signal fail (SF) at the far end of the protection line. This failure forces the received signal to be selected from the working line.

If the failure persists for 2.5 s, a Far-End Protection Line Failure alarm is raised. This alarm can only be raised by the active port operating in bidirectional mode. When the failure is absent for 10 s, the alarm is cleared.

3.2.17. T1/E1 Line Card Redundancy

This section contains information on the following topics:

3.2.17.1. T1/E1 LCR Overview

T1/E1 Line Card Redundancy (LCR) uses redundant adapter cards to protect T1/E1 services in case of hardware failures. T1/E1 LCR provides protection against adapter card or node failures. When T1/E1 LCR is used in conjunction with pseudowire redundancy, the network path between the endpoints is also protected. Protection is provided specifically for Cpipe services at the clear channel level and at the channelized level.

When T1/E1 LCR is enabled, the 7705 SAR constantly monitors the health of the adapter cards. If the active (working) adapter card fails (for example, because a card has been removed or due to a bus error), the system proceeds through a predefined sequence of steps to transfer (or switch over) traffic processing to the protection MDA. This switchover is done very quickly to minimize traffic loss. Traffic is moved to the protection adapter card until the fault on the working adapter card is cleared, at which time the traffic may optionally revert to the working adapter card.

T1/E1 LCR is supported on the following cards on 7705 SAR-8 (with CSMv2) and the 7705 SAR-18:

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

T1/E1 LCR includes support for single-chassis LCR (SC-LCR) and multi-chassis LCR (MC-LCR). In an SC-LCR group, both the working and protection adapter cards must be configured on the same node. In an MC-LCR group, the working adapter card and protection adapter card are configured on two separate nodes, providing protection from node failure in addition to protection from adapter card hardware failure.

3.2.17.2. SC-LCR

In an SC-LCR group, both the working and protection adapter cards are configured with the same LCR group ID on the same node. The working and protection adapter cards are required to be the same type.

SC-LCR is supported for TDM CES (Cpipes). SC-LCR with TDM access is supported on DS1, E1, and DS0 (64 kb/s) channels.

SC-LCR supports TDM SAP-to-SAP connections when both SAPs are configured as LCR SAPs.

SC-LCR also supports TDM SAP-to-spoke SDP connections over an MPLS network. In this configuration, the far-end connection may or may not be configured for LCR.

3.2.17.3. MC-LCR

MC-LCR extends the functionality offered by SC-LCR to include protection against 7705 SAR node failure. With MC-LCR, the working adapter card of an LCR group is configured on one 7705 SAR node while the protection adapter card of the same LCR group is configured on a different 7705 SAR node. The working and protection nodes are connected by an IP link (directly or indirectly) that establishes a multi-chassis protocol (MCP) link between the nodes.

MC-LCR is supported for TDM CES (Cpipes). MC-LCR with TDM access is supported on DS1, E1, and DS0 (64 kb/s) channels.

MC-LCR supports TDM SAP-to-SAP connections when both LCR SAPs are configured using the same adapter card on each node.

MC-LCR also supports TDM SAP-to-spoke SDP connections over an MPLS network. In this configuration, the far-end connection may or may not be configured for LCR.

The working and protection adapter cards must be the same type and must have compatible configurations, such as the same speed, framing, and port type. The adapter cards in an LCR group on both the working and protection nodes must also have the same group ID. The LCR groups can have different descriptions. In order for MC-LCR to function correctly, pseudowire redundancy must be configured on both the working and protection adapter cards. For information about pseudowire redundancy, refer to the 7705 SAR Services Guide, “Pseudowire Redundancy”. MC-LCR with pseudowire redundancy also supports Inter-Chassis Backup (ICB); see MC-LCR and Inter-Chassis Backup for more information.

Note:

The working and protection nodes can be different platforms, such as a 7705 SAR-8 and a 7705 SAR-18. However, to prevent possible switchover performance issues, avoid mixing different adapter card types in the same MC-LCR group. The 7705 SAR does not enforce configuration consistency between the working adapter card and the protection adapter card. Additionally, no service or network-specific configuration data is signaled or synchronized between the two nodes.

An MCP link can be established using the IP link between the two nodes by matching LCR group IDs. The signaling path verifies that one node is configured as the working adapter card and the other is configured as the protection adapter card. In case of a mismatch, an incompatible neighbor trap is generated. The protection node uses member adapter card status and the settings configured in the LCR Tools Commands to select the working adapter card. Changes in working adapter card status are sent across the MC-LCR signaling link from the working node to keep the protection node synchronized. External requests such as lockout and force switch are allowed only on the node with the protection adapter card.

3.2.17.3.1. MC-LCR and Inter-Chassis Backup

ICB spoke SDPs are supported for use with Cpipe services in an MC-LCR 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-LCR node to the protection node.

If the active link on the access side fails, an MC-LCR switchover is triggered and a pseudowire switchover is subsequently triggered. A failure on the network side triggers a pseudowire switchover but not an MC-LCR switchover. For detailed information on pseudowire redundancy with ICB protection, refer to the 7705 SAR Services Guide, “PW Redundancy and Inter-Chassis Backup”.

3.2.17.4. Revertive Mode

T1/E1 LCR provides revertive and non-revertive modes; non-revertive mode is the default option. In revertive mode, the activity is switched back to the working adapter card after it has recovered from a failure. In non-revertive mode, a switch to the protection adapter card is maintained even after the working adapter card has recovered from a failure.

To prevent frequent automatic switches that result from intermittent failures, a revert-time is defined for revertive switching. The revert-time is configurable from 0 to 60 min in increments of 1 min; the default value is 5 min. In some scenarios, performance issues can occur if the revert-time is set to 0; therefore, it is recommended that the revert-time always be set to a value of 1 or higher. Any change in the revert-time value takes effect upon the next initiation of the wait-to-restore (WTR) timer. The change does not modify the duration of a WTR timer that has already been started. The WTR timer of a non-revertive switch can be assumed to be infinite.

3.2.17.5. LCR Tools Commands

The LCR tools commands can only be executed on the node used in an SC-LCR group or on the protection node of an MC-LCR group. The commands can not be executed on the working node of an MC-LCR group.

3.2.17.5.1. Force Activity from Working Card

The tools>perform>lcr>force>working command forces activity away from the working adapter card to the protection adapter card so that the protection adapter card becomes active unless an internal request of equal or higher priority is already in effect. When this command is in effect, it can be overridden either by a tools>perform>lcr>lockout command or by a signal fault on the protection adapter card. If the protection adapter card is already the active adapter card, no action takes place. Refer to the 7705 SAR OAM and Diagnostics Guide, “Tools”, for information on the LCR force command.

3.2.17.5.2. Force Activity from Protection Card

The tools>perform>lcr>force>protect command forces activity away from the protection adapter card to the working adapter card so that the working adapter card becomes active unless an internal request of equal or higher priority is already in effect. Refer to the 7705 SAR OAM and Diagnostics Guide, “Tools”, for information on the LCR force command.

3.2.18. Deploying Preprovisioned Components

When a CSM or adapter card is installed in a preprovisioned slot, the system tests for discrepancies between the preprovisioned card and card type configurations and the types actually installed. Error messages are displayed if there are inconsistencies, and the card will not initialize. When the proper preprovisioned cards are installed into the appropriate chassis slot, then alarm, status, and performance details will be displayed on the CLI.

3.2.19. Microwave Link

This section contains information on the following topics:

3.2.19.1. Microwave Link Overview

A microwave link allows a 7705 SAR-8 or 7705 SAR-18 to be connected to a 9500 MPR-e radio node. The MPR-e is the zero-footprint (outdoor) microwave solution offered by Nokia that allows customers to migrate from TDM microwave to pure packet microwave. The following MPR-e radio variants are supported:

  1. MPT-MC - Microwave Packet Transport, Medium Capacity (ODU)
  2. MPT-HC V2/9558HC - Microwave Packet Transport, High Capacity Version 2 (ODU)
  3. MPT-XP - Microwave Packet Transport, High Capacity (very high power version of the MPT-HC V2/9558HC) (ODU)
  4. MPT-HQAM - Microwave Packet Transport, High Capacity (MPT-HC-QAM) or Extended Power (MPT-XP-QAM) with 512/1024 QAM (ODU)
  5. MPT-HLC and MPT-HLC plus - Microwave Packet Transport, High-Capacity Long-Haul Cubic (ANSI) (IDU)

A microwave link is configured on a 7705 SAR-8 or 7705 SAR-18 as a virtual port object (not as a physical port) using the CLI command mw-link-id (for more information on how to configure a microwave link, see Microwave Link Commands).

Note:

Before a microwave link can be configured, the current 7705 SAR software package that includes the MPR-e radio software must be downloaded from OLCS to the 7705 SAR-8 or 7705 SAR-18. See MPR-e Radio Software and Upgrade Management for more information.

The supported microwave link types are 1+0 and 1+1 Hot Standby (HSB). To deploy an N+0 link (with N ≥ 2), multiple links of 1+0 can be configured separately.

A microwave link connection is made from ports 1 through 4 on a Packet Microwave Adapter card to an MPR-e radio using one of the methods described in the 7705 SAR Packet Microwave Adapter Card Installation Guide, “Delivering Data to an MPR-e Radio”. The radio can be configured in standalone mode to provide a basic microwave connection as described in Standalone Mode or in Single Network Element (Single NE) mode to provide the advanced networking capabilities described in Single NE Mode. The default configuration is Single NE mode.

When connected to an MPR-e radio, these ports, with microwave link configured, operate as Gigabit Ethernet ports and provide the same features as the other ports (ports 5 through 8), except for the following:

  1. 802.1x authentication
  2. active/standby operation on Ethernet access ports configured as LAGs
  3. hard policing on Ethernet ports

If a microwave link is not configured on ports 1 through 4, they provide all of the same features as the other Gigabit Ethernet ports (ports 5 through 8).

3.2.19.2. Standalone Mode

A microwave link from ports 1 through 4 on a Packet Microwave Adapter card to an MPR-e radio that is configured in standalone mode provides a basic microwave connection to the MPR-e radio. In standalone mode, each MPR-e radio that is connected to a 7705 SAR-8 or 7705 SAR-18 is managed as a separate standalone NE by the MPT Craft Terminal (MCT) Element Manager.

3.2.19.3. Single NE Mode

A microwave link from ports 1 through 4 on a Packet Microwave Adapter card to an MPR-e radio that is configured in Single NE mode provides the following networking capabilities to the radio over the microwave link:

3.2.19.3.1. Single NE Management

MWA allows the 7705 SAR-8 or 7705 SAR-18 and the MPR-e radios to which it is connected to be integrated and managed as a Single NE. The following features are part of Single NE management:

3.2.19.3.1.1. One Management IP Address

The individual management and IP address of the MPR-e radios are no longer required for network management. When managing a microwave network (consisting of a 7705 SAR-8 or 7705 SAR-18 that is connected to one or more MPR-e radios) using an element/network manager, only the IP address of the 7705 SAR-8 or 7705 SAR-18 needs to be entered. This capability optimizes the microwave network’s IP addressing plan.

3.2.19.3.1.2. MPR-e Radio Configuration Management

For an MPR-e configuration, the required MWA-specific parameters are configured on the 7705 SAR side using the CLI and the required non-MWA parameters are configured on the MPR-e side using the MCT.

The following MWA-specific parameters are configured on the 7705 SAR side:

  1. 1+1 HSB parameters
  2. Epipe VLAN SAP parameters (in a mixed microwave link scenario, where there is interworking between a 7705 SAR MPR-e system and a Wavence MSS system using a TDM2Ethernet service, specific MPR-e system parameters are configured under the Epipe VLAN SAP; for more information, refer to the 7705 SAR Services Guide, “Configuring Epipe SAP Microwave Link Parameters for Interworking with TDM2 Ethernet”).

The following parameters are configured on the MPR-e side:

  1. radio link parameters
  2. QoS classification parameters

Configuration done on the MPR-e side is collected in a configuration file; this file can be saved to a 7705 SAR-8 or 7705 SAR-18 using the Commit button function on the MCT or an admin>save CLI command on the 7705 SAR-8 or 7705 SAR-18.

3.2.19.3.1.3. MPR-e Radio Alarm Management

An MPR-e radio generates alarms for fault conditions pertaining to the MPR-e hardware and to the microwave link over which it is connected. The alarms are sent to the 7705 SAR-8 or 7705 SAR-18, which turns the alarm notifications into SNMP traps and log events. These log events are controlled in the same way as all other events on the 7705 SAR-8 and 7705 SAR-18 and can be displayed using the show>log>event-control>mwmgr command. Refer to the 7705 SAR System Management Guide, “Event and Accounting Logs”, for more information.

3.2.19.3.1.4. MPR-e Radio Software and Upgrade Management

The Single NE capability optimizes the MPR-e radio software installation and upgrade process. The MPR-e radio software is bundled with the 7705 SAR software as one package, there is no need to look for and download the MPR-e radio software separately. The 7705 SAR software package containing the MPR-e radio software can be downloaded from a directory on OLCS. The operator can copy the software package onto a compact flash or network store on the 7705 SAR-8 or 7705 SAR-18.

Note:

There are two TiMOS .zip files on OLCS that contain the current 7705 SAR software package; the file that contains the MPR-e radio software has the .MWA annotation in the filename. Only the MPR-e radio software that is bundled with this 7705 SAR software package is recognized as being valid by the 7705 SAR-8 or 7705 SAR-18.

3.2.19.3.1.5. MPR-e Radio Configuration Database File Management

An MPR-e radio’s database file is stored and backed up on a 7705 SAR-8 or 7705 SAR-18. If an old MPR-e radio is replaced by a new one, the new MPR-e radio downloads the MPR-e radio software from the 7705 SAR-8 or 7705 SAR-18, along with the backed-up database file of the old MPR-e radio. This means that the MPR-e radio does not need to be reconfigured after a radio hardware replacement.

A separate database file is required for each managed MPR-e radio. The user specifies the filename of the database file to be used during provisioning of the radio on the 7705 SAR-8 or 7705 SAR-18 using the config>port>mw>radio>database CLI command.

3.2.19.3.1.6. MPR-e Radio Inventory and Microwave Link Performance Statistics

The following MPR-e radio system information and microwave link information and statistics can be accessed through a CLI session on the 7705 SAR-8 or 7705 SAR-18:

  1. MPR-e radio system information
    1. equipment type
    2. inventory information
    3. radio frequency band
    4. temperature
    5. radio transmit status
  1. microwave link statistics
    1. MPR-e radio Ethernet statistics
    2. local Tx power
    3. local Rx power
    4. remote Tx power
    5. remote Rx power
      Note:

      Local/remote Rx power monitoring and local/remote Tx power monitoring are also known as Receive Signal Level (RSL) monitoring and Transmit Signal Level (TSL) monitoring, respectively.

3.2.19.3.1.7. MPR-e Radio Reset Control

MPR-e radio reset control is provided on the 7705 SAR-8 or 7705 SAR-18. During an MPR-e radio reset, the microwave link is brought down and an upper layer applications action is triggered, such as message rerouting and clock source switching by the System Synchronization Unit (SSU).

3.2.19.3.1.8. MPR-e Radio Mute Control

MPR-e radio mute control can be enabled through the CLI/SNMP or by using the MCT. The MCT and CLI are synchronized to show the current state of the MPR-e radio mute function.

Note:

Administratively disabling the microwave link with which the MPR-e radio is associated (using the config>port>mw-link-id>shutdown command) causes the main and spare MPR-e radios to be muted.

3.2.19.3.2. Microwave Link Fast Fault Detection (FFD)

The microwave link Fast Fault Detection (FFD) capability allows a 7705 SAR-8 or 7705 SAR-18 to directly detect MPR-e radio or microwave link faults using proprietary messaging. The following fault types are detected by FFD:

  1. a radio signal failure
  2. an MPR-e radio hardware failure
  3. an incompatible MPR-e radio setting
  4. a High Bit Error Rate (HBER) condition
  5. a Remote Defect Indication (RDI) condition
Note:

  1. FFD does not cause the SSU to disqualify the microwave link as a clock source if a fault condition is detected; SSM must be enabled in order to provide this function.
  2. The microwave link hold time (hold-up time and hold-down time) must be configured in order to suppress link flapping. The hold-up and hold-down times delay advertising the transition of the microwave link status to the upper layer applications, including IP/MPLS and SSU. The hold-time range is between 0 and 900 s.

If microwave link faults are detected, an event is logged and the link is disabled. Some detected faults may be selectively suppressed using the suppress-faults command. When faults are suppressed, the event is still logged, but the microwave link is not disabled. Operators can suppress HBER faults, RSL threshold crossing faults, and/or RDI faults. By default, the system does not suppress faults for FFD.

3.2.19.3.3. 1+1 HSB

MWA uses 1+1 HSB to protect against microwave link, MPR-e radio, and Packet Microwave Adapter card failures, as well as frequency channel selective fading. Additionally, hitless (errorless) switching provides zero packet loss if a switchover occurs from a main to a spare MPR-e radio.

The following are required for 1+1 HSB:

  1. one frequency channel
  2. two MWA Gigabit Ethernet ports (configured in network mode) on two different Packet Microwave Adapter cards installed in adjacent slots (for example, slot 1/2 or slot 5/6); port 1 on one card protects port 1 on the adjacent card, port 2 protects port 2 on the adjacent card, and so on.
  3. two MPR-e radios (one main and one spare), each connected to one of the MWA Gigabit Ethernet ports on a Packet Microwave Adapter card
    Note:

    An MPR-e radio that is connected to an odd-numbered port on the Packet Microwave Adapter card must be configured as the main radio.

The following protection schemes make up 1+1 HSB:

These protection schemes are enabled using the config>port>mw>protection command, with the exception of Transmit Diversity Antenna, which is enabled via the MCT. They interwork with each other as described in the sections that follow.

3.2.19.3.3.1. 1+1 Equipment Protection Switching (EPS)

EPS protects against MPR-e radio, MWA Gigabit Ethernet link, and Packet Microwave Adapter card failures. After the radio frames are processed by the active EPS MPR-e radio, the radio sends the Ethernet traffic down to the 7705 SAR-8 or 7705 SAR-18. The standby EPS MPR-e radio does not send any Ethernet traffic down to the 7705 SAR-8 or 7705 SAR-18.

The switching criteria for EPS are:

  1. an MPR-e radio hardware failure
  2. an MWA Gigabit Ethernet link failure between the 7705 SAR-8 or 7705 SAR-18 and an MPR-e radio
  3. a Packet Microwave Adapter card connected to an active EPS MPR-e going into a missing or failure state

3.2.19.3.3.2. 1+1 Transmission Protection Switching (TPS)

In a 1+1 HSB configuration, TPS protects against a microwave link transmission failure by ensuring that only one MPR-e radio at a time uses the antenna for signaling. The 7705 SAR-8 or 7705 SAR-18 sends traffic to both the active and standby TPS MPR-e radios. Upon receiving the baseband traffic, both radios modulate it and up-convert it to signals. However, only the active TPS MPR-e radio transmits the RF signals; the standby TPS MPR-e radio suppresses the signals. When the active TPS MPR-e radio fails, standby radio becomes active and restores the microwave link channel.

The switching criteria for TPS are identical to EPS.

Note:

  1. The state of the EPS and TPS MPR-e radios are linked to each other. If an alarm occurs, an automatic switchover for EPS and TPS is activated simultaneously. However, if a manual switchover is configured, the switchover is decoupled and the state of the EPS and TPS MPR-e radios is no longer identical.
  2. A manual switchover can be configured for EPS but not for TPS.

3.2.19.3.3.3. 1+1 Radio Protection Switching (RPS)

RPS is a hitless radio function that provides space diversity protection for the microwave channel. On the receive side, each MPR-e radio monitors the same radio frequency channel, with the main MPR-e radio being the active receiver by default. Both active and standby RPS MPR-e radios receive both streams of radio frames. The standby RPS MPR-e radio sends the stream of radio frames that it receives to the active EPS MPR-e radio.

Note:

In order to provide space diversity (SD) for the two radio frequency channels, RPS requires that a separate antenna be mounted for each MPR-e radio.

Figure 18 shows a typical application of 1+1 HSB with SD deployment. Only one microwave frequency channel is active and only the main MPR-e radio is transmitting data to the remote ends; the spare MPR-e radio is acting as a standby.

Figure 18:  1+1 HSB with SD Deployment 

3.2.19.3.3.4. 1+1 HSB Transmit Diversity Antenna (TDA)

The TDA feature provides another layer of protection over a microwave link. The TDA configuration uses a main antenna mounted on one MPT-HLC or HLC plus radio and a diversity antenna mounted on another MPT-HLC or HLC plus radio. In combination with the 1+1 HSB radio configuration (redundant MPR-e radios), the traffic is transmitted on either the main antenna or the diversity antenna to achieve the Space Diversity (SD) receiver configuration.

TDA provides protection switching independent of TPS. TDA is capable of counter-acting either negative propagation conditions or permanent antenna failure.

The main antenna is the default main unit that controls the antenna traffic flow using the TDA algorithm. If the main unit fails, the TDA algorithm is no longer operational on the main unit; its transmission switches over to the diversity antenna.

The non-operation of the main antenna switch does not affect transmission, even while the TDA algorithm is being transmitted on the diversity antenna.

TDA configuration is done via the MCT. TDA status is available using the 7705 SAR CLI/SNMP and via the MCT. The CLI command that is used is show>mw>link. The status information includes the current TDA configuration, which antenna is active, and the active antenna position.

Figure 19 shows an example of a TDA application.

Figure 19:  Example of a TDA Application 

3.2.19.3.3.5. Communication Method Between the Main and Spare MPR-e Radio

In a 1+1 HSB configuration, the communication path between the main (active) and spare (standby) MPR-e radios installed on a tower is set up using a tight cable.

Note:

A tight cable is required with MPT-HC V2, MPT-XP, MPT-HLC, MPT-HLC plus, and MPT-QAM radios (1+ 1 HSB is not supported on MPT-MC radios).

3.2.19.3.4. 1+1 Switching Operation

The following list defines the types of EPS, TPS, and RPS MPR-e radio switching operations that can be enabled using the tools>perform>mw>link command. Refer to the 7705 SAR OAM and Diagnostics Guide, “Tools Command Reference”, “Tools Perform Commands”, for more information.

Note:

TDA switching operation is enabled via the MCT.

  1. lockout—prevents the spare MPR-e radio from ever becoming the main radio, even when the main MPR-e radio fails; this operation overrides any forced, automatic, or manual operation
  2. forced —forces the spare MPR-e radio to become the main MPR-e radio, even though it might not be in a fit state to assume the role. A forced switch operation overrides any automatic or manual switch operation that is in place.
  3. automatic—allows an MPR-e radio to perform an automatic switchover if a fault condition exists. An automatic switch operation overrides any manual switch operation that is in place.
  4. manual—attempts to switch the main/spare status of an MPR-e radio; however, if port failures, equipment failures, and reception failures do not allow the switchover, an automatic switch operation is triggered.

You can also configure revertive switching for RPS and EPS/TPS (when revertive switching is configured for EPS, it is also applied to TPS; revertive switching for TPS cannot be configured separately). Revertive switching occurs when the MPR-e radio operation switches from the spare radio back to the main radio after a fault condition is cleared.

3.2.19.4. Frequency Synchronization

Depending on the type of Gigabit Ethernet microwave link used to connect the Packet Microwave Adapter card and an MPR-e radio, different frequency synchronization mechanisms can be used.

When using optical 1000Base-SX to connect the Packet Microwave Adapter card and an MPR-e radio, synchronous Ethernet and SSM are the frequency synchronization mechanisms that are used. SSM is used as the mechanism to detect a microwave link failure, including loss of frame and MPR-e radio hardware failure.

When using electrical 1000Base-T to connect the Packet Microwave Adapter card and an MPR-e radio, PCR is the frequency synchronization mechanism that is used (a copper SFP is mandatory on ports 3 and 4).

For more information on PCR, synchronous Ethernet, and SSM, refer to the 7705 SAR Basic System Configuration Guide, “Node Timing”.

3.2.19.5. RSL History

An MPR-e radio that is connected to the 7705 SAR can automatically upload its received signal level (RSL) history file to the 7705 SAR host. The RSL file contains a history of radio attributes and alarms that radio operators can use to isolate and diagnose radio-layer problems that might exist in the network.

Up to 24 MPR-e radios can independently upload their RSL history file every 15 minutes when the rsl-history command is configured on the 7705 SAR for each radio. When uploaded, the file is stored on the 7705 SAR compact flash. Each RSL file can be up to 1 Mbyte and contain up to 10 000 lines. Each time a new file from a specific MPR-e radio is sent to the 7705 SAR, the new file overwrites the previous version for that radio. Once uploaded to the 7705 SAR, the operator can view the file in its raw format using the file>type command or FTP it to an external server.

Table 21 lists the attributes in the RSL history file.

Table 21:  RSL History Attributes  

Attribute

Description

Time

Time of record

LocTxPower

Local transmit power

RemTxPower

Remote transmit power

LocRxPower

Local received power

RemRxPower

Remote received power

LocDivRxPower

Local diversity received power (significant for diversity configuration only)

RemDivRxPower

Remote diversity received power (significant for diversity configuration only)

LocXPD

Local cross-polar discrimination (significant for XPIC configuration only)

RemXPD

Remote cross-polar discrimination (significant for XPIC configuration only)

LocMSE

Local mean squared error

RemMSE

Remote mean squared error

TxMod

Transmitter modulation

RxMod

Receiver modulation

LocEPS

Local equipment protection switching

RemEPS

Remote equipment protection switching

LocRPS

Local radio protection switching

RemRPS

Remote radio protection switching

LocTPS

Local transmit protection switching

RemTPS

Remote transmit protection switching

LocHBERAlm

Local high bit error rate alarm

RemHBERAlm

Remote high bit error rate alarm

LocEWAlm

Local early warning alarm

RemEWAlm

Remote early warning alarm

LocDemFailAlm

Local demodulation failure alarm

RemDemFailAlm

Remote demodulation failure alarm

3.2.20. DSL Bonding

This section contains information on the following topics:

3.2.20.1. DSL Bonding Overview

The 7705 SAR-M (variants with module slots) supports two DSL modules designed to transport high-volume, best-effort HSDPA traffic or to be used as a pure DSL backhaul option. The 6-port DSL Combination module supports four G.SHDSL.bis pairs and two ADSL2, ADSL2+, or VDSL2 pairs. The 8-port xDSL module supports eight pairs of ADSL2, ADSL2+, or VDSL2.

The 7705 SAR-Wx variants that support Ethernet and xDSL each provide 4-pair xDSL PTM bonding (ADSL2+ or VDSL2) on the RJ-45 xDSL port. Refer to the 7705 SAR-Wx Chassis Installation Guide for more information on the xDSL port on the 7705 SAR-Wx.

DSL bonding allows multiple physical DSL links to be combined in one logical link to increase bit rate capacity to the subscriber and/or extend the reach of existing services. DSL bonding is activated by the handshake messages between the Central Office and CPE as defined in ITU-T G.994.1. Once the port is configured for bonded mode, any pairs not included in the bonded groups cannot be used to carry traffic.

The 6-port DSL Combination module supports up to two bonding groups, one for SHDSL and one for xDSL. The 8-port xDSL module and the RJ-45 xDSL port on the 7705 SAR-Wx support only one bonding group. The DSLAM handshake determines the number of DSL pairs used in each bonding group as shown in Table 22.

Table 22:  DSL Pairs by Bonding Group 

Bonding Group

6-port DSL Combination Module DSL Pairs

8-port xDSL Module DSL Pairs

7705 SAR-Wx RJ-45 xDSL Port DSL Pairs

xDSL PTM

1 to 2

1 to 8

1 to 4

SHDSL

2 to 4

ADSL2/ADSL2+ ATM

1 to 2

1 to 2

Bonding functions are driven entirely by the Central Office with the exception of the ATM VPI/VCI when ATM bonding is used on an xDSL interface.

The 7705 SAR-M supports both ATM and PTM bonding. The 7705 SAR-Wx supports PTM bonding.

3.2.20.2. ATM Bonding

ATM bonding is specified by ITU-T G.998.1 and is used for ATM-based transmission links for all types of ADSL. ATM bonding adds sequence information to ATM cells, allowing resequencing by adding delay variation to account for speed differences across multiple physical links in one bonding group. ATM bonding is sometimes referred to as multi-ADSL bonding because multiple ADSL lines typically use ATM-based transmission links.

ATM bonding acts as an alternative to IMA as a method of logically combining multiple lines transmitting ATM cells. ATM bonding differs from IMA in the following ways:

  1. ATM links can run at different rates
  2. differential delay does not need to be constant, but should be controlled to minimize buffering requirements
  3. the traffic header of transported ATM cells is modified to carry a sequence ID
  4. traffic is distributed to the links at the discretion of the transmitter, rather than strict round-robin order

The 8-port xDSL module and the xDSL interface of the 6-port DSL Combination module support 2-pair ATM bonding for ADSL2 and ADSL2+. When operating in ATM bonded mode, the remaining 6 pairs on the 8-port xDSL module cannot be used. Additionally, the only protocol stack supported is Ethernet over ATM with RFC 2684 LLC/SNAP bridged ATM packets. In ATM bonded mode, cell scrambling is always enabled and ATM CLP is disregarded (it is not set or inspected for priority loss indications). Any packet priority marking must be done at the Ethernet, MPLS, or IP layers.

In ATM channel-bonding schemes, the end-user packets are split into 53-byte cells. Each cell is tagged with a sequence ID by replacing bits in the ATM header with sequence ID (SID) bits between bonding entities. The ATM bonding implementation on the 7705 SAR-M currently only supports a 12-bit SID, although G.998.1 specifies support for either an 8-bit or 12-bit SID bound by the aggregate rate, differential delay, and number of links.

For ATM bonding, all bridged PDUs are sent without an FCS field. However, if an attached DSLAM does send bridged PDUs with an FCS field attached, the FCS is honored and is not removed or regenerated.

3.2.20.3. PTM Bonding

PTM bonding is specified by ITU-T G.998.2 and is supported on VDSL2, ADSL2, and ADSL2+ interfaces on the 6-port DSL Combination module and 8-port xDSL module, and on SHDSL on the 6-port DSL Combination module. The 7705 SAR-Wx variants that support Ethernet and xDSL provide 4-pair xDSL PTM bonding (ADSL2+ or VDSL2) on the RJ-45 xDSL port.

PTM bonding and EFM bonding are sometimes used interchangeably, with EFM bonding generally used in conjunction with SHDSL. The SHDSL interface on a 6-port DSL Combination module complies with both PTM specified in ITU-T G.998.2, and EFM specified in IEEE 802.3ah-2004.

PTM bonding applies to DSL links with or without identical transmission speeds. Since PTM implies the use of variable-size PDUs, it makes the use of IMA techniques impossible. PTM bonding combines EFM-based transmission links with limited, or reach-dependent, bandwidth, specifically VDSL2, SHDSL, or ADSL2+ on the 7705 SAR-M and ADSL2+ or VDSL2 on the 7705 SAR-Wx. PTM bonding adds sequence information to transmitted frames or frame fragments, allowing resequencing by adding delay variation to account for speed and PDU size differences across multiple physical links in one bonding group.

In PTM channel-bonding schemes, the end-user packets are split into small fragments of up to 512 bytes. The PTM bonding implementation on xDSL ports uses a fixed fragment size of 204 bytes, which is not user-configurable. The PTM fragment size on the SHDSL ports is set to 256 bytes. When PTM bonding is active on a DSL bundle, fragments are distributed over individual DSL lines. At the receiving end, the fragments are realigned to recover from differential delays in the transmission path, then reassembled into packets.

In order to realign correctly, each fragment is prefixed with a header containing a sequence identifier (SID), a start of packet (SOP) indicator, and an end of packet (EOP) indicator. The receiver side uses the SID to rearrange the incoming cells in the correct order, while the SOP and EOP indications are used to reassemble the stream of cells into complete data packets. If transmitted Ethernet packets are smaller than the PTM fragment size, they are transmitted inside a single fragment.

3.2.20.4. Pairs Within a Bonded Group

Pairs within a bonded group must start with pair 1 and are then sequentially added into each module or port. For example, if a 4-pair bonded group is desired on an interface capable of supporting 4 or more pairs, pairs 1 through 4 should be connected to the DSLAM and configured by the DSLAM into the bonded group. For pinout diagrams, refer to the 7705 SAR DSL Module Installation Guide for RJ-11 pinouts and the 7705 SAR-Wx Chassis Installation Guide for RJ-45 pinouts.

On the ISAM, bonding makes use of either chipset or LT-level (Line Termination card-level) bonding. For LT-level bonding, the interworking function on the LT board allows non-contiguous ports on the same LT to be bonded. LT-level bonding is used to configure 8-pair bonding on the ISAM, which is also handled by dedicated hardware that incorporates both bonding and xDSL interworking functions. SHDSL bonding functions are provided on the ISAM via chipset level bonding.

Within a bonding group, the line used to identify the whole group is referred to as the primary link. The other lines in the bonding group are referred to as secondary or slave links. The supported bit rate over the bonding group is the sum of the actual net bit rates on all lines in the group.

3.2.20.5. Configuration

All DSL ports are considered the functional equivalent of an Ethernet port and support many of the same features and configuration commands. Data from the router’s central network processor transmit and receive Ethernet packets to and from the 7705 SAR-M module slot or 7705 SAR-Wx port.

If xDSL lines train in ATM bonding mode over ADSL2/2+, the VPI/VCI configured on that port is used by the module or platform to interwork Ethernet packets into AAL5 LLC snap-bridged PDUs without user intervention.

All lines for both the 6-port DSL Combination module and the 8-port xDSL module are configured from the ISAM via the G.994.1 (G.hs) handshake. All lines operate in auto-detect mode; therefore, there are no individual line configurations required with the exception of the configuration of VPI/VCI for ATM bonding and the configuration of ADSL2/2+ Annex B support if ISDN support is required, on an xDSL interface.

DSL modules and ports automatically detect any existing configuration and will attempt to bring pairs into service. For PTM bonding, the underlying transport mechanism is Ethernet. For ADSL2+ ATM bonding, the underlying transport mechanism is ATM, which requires a configured VPI/VCI. The default VPI/VCI on the 7705 SAR-M is 8/35, and only a single VC can be configured.

The only mode of operation for all SHDSL and xDSL pairs on the 7705 SAR-M is bonded mode. On the 7705 SAR-Wx, the only mode for xDSL pairs is PTM bonded mode.

Log files are created to record critical events during xDSL and SHDSL chipset initialization and for any DSL-related operational events. The log file can be viewed through the CLI or the NSP NFM-P for debugging and troubleshooting. The event data can be directed to the default log file or to a specific user-configured log file.

The CLI commands to configure DSL are found under the config>port>dsl context.

3.2.20.6. Layer 3 Protocol Support and Service Provisioning

Table 23 lists the limits for the 6-port DSL Combination module, the 8-port xDSL module, and the RJ-45 xDSL port on the 7705 SAR-Wx.

Table 23:  DSL Module and Port Limits 

6-port DSL Combination module

8-port xDSL module

7705 SAR-Wx RJ-45 xDSL port

SHDSL

xDSL

Maximum number of bonding groups

1

1

1

1

PTM bonding group size

2 to 4 pairs

1 to 2 pairs

1 to 8 pairs

1 to 4 pairs

ATM bonding group size

1 to 2 pairs

1 to 2 pairs

MTU

2048 bytes

Only validated to 1594 bytes due to ISAM

2000 bytes

Only validated to 1980 bytes due to ISAM

2000 bytes

Only validated to 1980 bytes due to ISAM

2000 bytes

Only validated to 1980 bytes due to ISAM

Maximum downstream/ upstream user data rate

8-pair bonding

350/350 Mb/s (with a trained group rate of 800/400M US/DS)

4-pair bonding

21 Mb/s (with a trained data rate of 22.784 Mb/s symmetrically)

191/100 Mb/s with 2-pair bonding

350 Mb/s DS rate

191/100 Mb/s with 2-pair bonding

2-pair bonding

10 Mb/s (with a trained data rate of 11.392 Mb/s symmetrically)

191/100 Mb/s (with a trained line rate of 200/103 Mb/s US/DS)

191/100 Mb/s (with a trained line rate of 200/103 Mb/s US/DS)

191/100 Mb/s (with a trained line rate of 200/103 Mb/s US/DS)

3.2.21. Custom Alarms on Ethernet Ports

The 7705 SAR supports custom alarms on Ethernet ports without the need to deploy a dry-contact alarm aggregator. Custom alarms can be created and assigned to any RJ-45 port; the port must be configured for 100Base-Tx operation with autonegotiation disabled. One alarm input can be configured for each port with the following:

  1. name
  2. description
  3. association with a user-defined alarm

Alarm inputs must be associated with an alarm in order for them to be triggered. Alarm inputs consist of an Ethernet LOS event caused by breaking contact loops between pins 1 and 3 or 2 and 6 on the Ethernet port. Breaking either loop will trigger the port alarm, and reconnecting the loops will clear the alarm.

For information on configuring the alarm inputs, see Configuring Auxiliary Alarm Card, Chassis, and Ethernet Port External Alarm Parameters.

3.3. 802.1x Network Access Control

The 7705 SAR supports network access control over client devices on an Ethernet network using the IEEE 802.1x standard. 802.1x is a standard for authenticating Ethernet devices before they can access the network. In the case of the 7705 SAR, authentication is performed using Extensible Authentication Protocol (EAP) over LAN (EAPOL).

802.1x provides protection against unauthorized access by forcing the device connected to the 7705 SAR to go through an authentication phase before it is able to send any non-EAP packets. Only EAPOL frames can be exchanged between the aggregation device (called the authenticator; for example, the 7705 SAR) and the customer device (called the supplicant) until authentication is successfully completed. The 7705 SAR enables the port after successful authentication. While the port is unauthenticated, the port will be “down” to all upper layer protocols or services.

A typical use for EAPOL would involve a 7705 SAR and some type of Ethernet device, such as a laptop, a set-top box, or a Node B. An authentication server would negotiate with the Ethernet device through the 7705 SAR (whose role is authenticator). For example, a technician using a laptop to gain access to his or her network at a cell site would have his or her laptop subject to the 802.1x access control, just as the Node B would. In every case, the Ethernet device connected to the 7705 SAR must negotiate for network access. Essentially, with EAPOL in use, any Ethernet device that connects to the 7705 SAR must negotiate for permission to send traffic through the 7705 SAR Ethernet port.

The 7705 SAR supports the following EAP methods: MD5, TLS, TTLS, and PEAPv0.

MAC authentication can be used to authenticate client devices that do not support EAP. For more information, see MAC Authentication.

This section describes the following:

3.3.1. 802.1x Basics

The IEEE 802.1x standard defines three participants in an authentication conversation (see Figure 20):

  1. the supplicant — the end-user device that requests access to the network
  2. the authenticator — controls access to the network. Both the supplicant and the authenticator are referred to as Port Authentication Entities (PAEs).
  3. the authentication server — performs the actual processing of the user information
Figure 20:  802.1x Architecture 

The authentication exchange is carried out between the supplicant and the authentication server; the authenticator acts only as a bridge. The communication between the supplicant and the authenticator is done using EAPOL. The communication between the authenticator and the authentication server is done using the RADIUS protocol. The authenticator is therefore a RADIUS client, and the authentication server is a RADIUS server.

Figure 21 shows an example of the messages transmitted during an authenticator-initiated One Time Password (OTP) authentication process.

Note:

 OTP is one of many authentication mechanisms that are available for use between the supplicant and the authentication server. These authentication mechanisms (protocols) are transparent to the 7705 SAR.

Figure 21:  Authentication Scenario 

The authenticator initiates the procedure when the Ethernet port becomes operationally up by sending a special PDU called an EAP-Request/ID to the supplicant. The supplicant can also initiate the exchange by sending an EAPOL-start PDU if it does not receive the EAP-Request/ID frame during boot-up. The supplicant responds to the EAP-Request/ID with an EAP-Response/ID frame containing its identity (typically username + password).

After receiving the EAP-Response/ID frame, the authenticator encapsulates the identity information into a RADIUS Access Request packet, and sends it off to the configured RADIUS server. The RADIUS Access Request packet contains the following attributes:

  1. User-Name – the name of the supplicant to be authenticated
  2. Calling-Station-Id – the MAC address of the supplicant
  3. NAS-IP-Address – the IP address of the device acting as the authenticator
  4. NAS-Port – the physical port number of the device acting as the authenticator
  5. State – allows state information to be maintained between the authenticator and the RADIUS server
  6. EAP-Message – used to encapsulate EAP packets for transmission from the authenticator to the RADIUS server
  7. Message-Authenticator – used to authenticate and protect the integrity of Access Request messages in order to prevent spoofing attacks

The RADIUS server checks the supplied credentials using an authentication algorithm to verify the supplicant’s identity. If approved, the RADIUS server returns an Access Accept message to the authenticator. The authenticator notifies the supplicant with an EAP-Success message and puts the port in the authorized state.

If the supplicant sends an EAP-Logoff message, the authenticator puts the supplicant in an unauthorized state and continues searching for supplicants to authenticate.

After sending an EAP-Failure message, the authenticator puts the supplicant in an unauthorized state, waits for the number of seconds defined by the quiet-period timer, then continues searching for supplicants to authenticate.

The 7705 SAR conforms to the relevant sections of the 802.1X-2001 implementation.

3.3.2. 802.1x Modes

The 7705 SAR supports port-based network access control for Ethernet ports only. Each Ethernet port can be configured to operate in one of three different modes, controlled by the port-control command:

  1. auto — enables 802.1x authentication. The port starts in the unauthorized state, allowing only EAPOL frames to be sent and received through the port. Both the authenticator and the host (supplicant) can initiate an authentication process as described earlier. The port will remain in the unauthorized state until the first supplicant is authenticated successfully. After this, traffic is allowed on the port for all connected hosts.
  2. force-auth — disables 802.1x authentication and causes the port to transition to the authorized state without requiring any authentication exchange. The port transmits and receives normal traffic without requiring 802.1x-based host authentication. This is the default setting.
  3. force-unauth — causes the port to remain in the unauthorized state, ignoring all attempts by the hosts to authenticate. The authenticator cannot provide authentication services to the host through the interface.

3.3.3. 802.1x Timers

The 802.1x authentication process is controlled by a number of configurable timers. There are two separate sets, one for the EAPOL message exchange and one for the RADIUS message exchange. Figure 22 shows an example of the timers.

Figure 22:  802.1x EAPOL Timers and RADIUS Timers 

EAPOL timers:

  1. transmit-period — indicates how many seconds after sending an EAP-Request/ID frame that the 7705 SAR will listen for a supplicant to authenticate (by sending a EAP-Response/ID frame). If the timer expires before a response is received, a new EAP-Request/ID frame will be sent and the timer restarted. The default value is 30 s. The range is 1 to 3600 s.
  2. supplicant-timeout — indicates how many seconds to allow the 7705 SAR to complete the authentication process. This timer is started at the beginning of a new authentication process (transmission of first EAP-Request/ID frame and receipt of an EAP-Response/ID frame). If the timer expires, the 802.1x authentication session is considered to have failed and the 7705 SAR waits for the quiet-period timer to expire before processing another authentication request. The default value is 30 s. The range is 1 to 300 s.
  3. quiet-period — indicates the number of seconds that the authenticator will not search for clients after an unsuccessful EAP authentication. The timer is started after sending an EAP-Failure message or after expiry of the supplicant timeout timer. The default value is 60 s. The range is 1 to 3600 s.

RADIUS timers:

  1. max-auth-req — indicates the maximum number of times that the authenticator will send an authentication request to the RADIUS server before the process is considered as to have failed. The default value is 2. The range is 1 to 10.
  2. server-timeout — indicates how many seconds the authenticator will wait for a RADIUS response message. If the timer expires, the access request message is sent again, up to the max-auth-req value, and the timer is reset. The default value is 30 s. The range is 1 to 300 s.

The authenticator can also be configured to periodically trigger the authentication process automatically. This is controlled by the enable reauthentication and reauthentication period parameters. Re-auth-period indicates the time in seconds (since the last time that the authorization state was confirmed) before a new authentication process is started. The range of re-auth-period is 1 to 9000 s (the default is 3600 s). The port stays in an authorized state during the reauthentication process.

3.3.4. 802.1x Configuration and Limitations

Configuration of 802.1x network access control on the authenticator consists of two parts:

  1. generic parameters, which are configured under config>system>security>dot1x
    Refer to the Basic System Configuration Guide, “System Command Reference”.
  2. port-specific parameters, which are configured under config>port>ethernet>dot1x

802.1x provides access to the port for any device, even if only a single client has been authenticated. Additionally, it can only be used to gain access to a predefined Service Access Point (SAP). It is not possible to dynamically select a service (such as a VPLS service) depending on the 802.1x authentication information.

3.4. MAC Authentication

The 7705 SAR supports the 802.1x EAP standard for authenticating Ethernet devices before they can access the network. However, if a client device does not support 802.1x EAP, MAC authentication can be used to prevent unauthorized traffic from being transmitted through the 7705 SAR.

802.1x EAP must be enabled for MAC authentication to be used, as MAC authentication is a fallback mechanism. To authenticate a port using MAC authentication, 802.1x authentication must first be configured on the 7705 SAR by enabling port-control auto, and then mac-auth must be configured on the 7705 SAR to enable MAC authentication.

When a port becomes operationally up with MAC authentication enabled, the following steps are performed by the 7705 SAR (as the authenticator):

  1. After transmission of the first EAP-Request/ID PDU, the 7705 SAR starts the mac-auth-wait timer and begins listening on the port for EAP-Response/ID PDUs. At this point, the 7705 SAR only listens to EAPOL frames. If EAPOL frames are received, 802.1x authentication is chosen.
    Note:

    If it is known that the attached equipment does not support EAP, no mac-auth-wait can be configured so that MAC authentication can be used as soon as the port is operationally up.

  2. If the mac-auth-wait timer expires, and no EAPOL frames have been received, the 7705 SAR begins listening on the port for any Ethernet frames.
  3. If the 7705 SAR receives an Ethernet frame, the 7705 SAR scans the client source MAC address in the frame and transmits the MAC address to the configured RADIUS server for comparison against the MAC addresses configured in its database.
    The following attributes are contained in the RADIUS message:
    1. User-Name – the source MAC address of the client device
    2. User-Password – the source MAC address of the client device in an encrypted format
    3. Service-Type – the type of service that the client has requested; the value is set to 10 (call-check) for MAC authentication requests
    4. Calling-Station-Id – the source MAC address of the client device
    5. NAS-IP-Address – the IP address of the device acting as the authenticator
    6. NAS-Port – the physical port of the device acting as the authenticator
    7. Message-Authenticator – used to authenticate and protect the integrity of Access Request messages in order to prevent spoofing attacks
  4. If the MAC address is approved by the RADIUS server, the 7705 SAR enables the port for traffic transmission.
    If the MAC address is rejected by the RADIUS server, the 7705 SAR enters a quiet period, configured using the quiet-period command, and will not authenticate the port via either 802.1x or MAC authentication. After the quiet period expires, the 7705 SAR returns to step 1.
  5. If a port that was previously authenticated with MAC authentication receives an EAPOL-Start frame, the port will reauthenticate using 802.1x EAPOL.

While the port is unauthenticated, the port will be “down” to all upper layer protocols or services.

3.5. Link Layer Discovery Protocol (LLDP)

The IEEE 802.1ab Link Layer Discovery Protocol (LLDP) allows stations that are attached to the same IEEE 802 LAN (emulation) to advertise information for the purpose of populating physical or logical topology and device discovery management information databases. In other words, IEEE 802.1ab Link Layer Discovery Protocol allows an LLDP agent to learn connectivity and management information from adjacent stations. The information obtained via this protocol is stored in standard MIBs which can be accessed via management protocols such as SNMP.

LAN emulation and logical topology is applicable to customer bridge scenarios (enterprise or carrier of carrier) connected to a provider network offering a transparent LAN emulation service to their customers. LAN emulation helps customers detect intermediate provider misconnections by offering a view of the customer topology where the provider service is represented as a LAN interconnecting customer bridges.

The IEEE 802.1ab standard defines a protocol that:

  1. advertises connectivity and management information about the local station to adjacent stations on the same IEEE 802 LAN
  2. receives network management information from adjacent stations on the same IEEE 802 LAN
  3. operates with all IEEE 802 access protocols and network media
  4. establishes a network management information schema and object definitions that are suitable for storing connection information about adjacent stations
  5. provides compatibility with a number of MIBs as shown in Figure 23
Figure 23:  LLDP Internal Architecture for a Network Node 

Network operators must be able to discover the topology information in order to detect and address network problems and inconsistencies in the configuration. Standards-based tools can address complex network scenarios where multiple devices from different vendors are interconnected using Ethernet interfaces.

The 7705 SAR platforms, cards, and modules support LLDP on all Ethernet datapath ports. On the 2-port 10GigE (Ethernet) Adapter card/module, LLDP is supported on the Ethernet ports, but not on the v-port. Each Ethernet port can be configured to run up to three LLDP sessions. Each session can have up to five peers and each peer can store up to three management addresses.The 7705 SAR can have a maximum of 720 peers configured.

Figure 24 shows the three scopes of LLDP that are supported on the 7705 SAR. The scopes are Nearest Bridge, Nearest non-TPMR Bridge, and Nearest Customer Bridge.

Figure 24:  Network Example For LLDP 

3.5.1. LLDP Protocol Features

LLDP allows stations attached to an IEEE 802 LAN to advertise to other stations attached to the same LAN, the major capabilities provided by the system incorporating that station, the management address or addresses of the entity or entities that manage these capabilities, and the identification of the station's point of attachment to the LAN required by the management entity or entities.

The information distributed via this protocol is stored on the receiving device in a standard MIB, so that the information can be accessed by a Network Management System (NMS).

The LLDP protocol uses an LLDP agent entity that implements LLDP for a particular MAC service access point (MSAP) associated with a port.

LLDP does not contain a mechanism for soliciting specific information from other LLDP agents, nor does it provide a specific means of confirming the receipt of information. LLDP allows the transmitter and the receiver to be enabled separately; therefore, the local LLDP agent can be configured to transmit only, receive only, or both transmit and receive LLDP information.

LLDP agents transmit and receive LLDP Data Units (LLDPDUs). The LLDPDU contains an LLDP frame whose information fields are a sequence of variable-length information elements. Each element includes type, length, and value fields (known as TLVs).

  1. Type identifies what kind of information is being sent.
  2. Length indicates the length of the information string in octets.
  3. Value is the actual information that needs to be sent; for example, a binary bit map or an alphanumeric string that can contain one or more fields.

Each LLDPDU contains four mandatory TLVs and can contain optional TLVs as selected by network management. Figure 25 shows the LLDPDU format.

Figure 25:  LLDPDU Format 

The chassis ID TLV identifies the chassis containing the Ethernet port responsible for transmitting the LLDPDU. The port ID TLV identifies the Ethernet port responsible for transmitting the LLDPDU. The chassis ID and the port ID values are concatenated to form a logical identifier (the MSAP identifier) that is used by the recipient to identify the sending LLDP agent and associated port. Both the chassis ID and port ID values can be defined in a number of ways. Once selected, however, the chassis ID and port ID value combination remains the same as long as the particular port remains operable.

The Time To Live TLV indicates the number of seconds (from 0 to 65535) that the receiving LLDP agent should consider the information contained in the received LLDPDU to be valid. The Time To Live TLV is calculated by the formula tx-interval × tx-hold-multiplier. The associated information is automatically discarded by the receiving LLDP agent if the sender fails to update it before this time. A zero value indicates that any information pertaining to this LLDPDU identifier is to be discarded immediately. A TTL value of zero can be used, for example, to signal that the sending port has initiated a port shutdown procedure.

The End of LLDPDU TLV marks the end of the LLDPDU.

The implementation defaults to setting the port-id field in the LLDP OAMPDU to tx-local. This encodes the port-id field as ifindex (subtype 7) of the associated port, which is required to support some releases of the NSP NFM-P. The NSP NFM-P may use the ifindex value to properly build the Layer 2 topology network map. However, this numerical value is difficult to interpret or readily identify the LLDP peer when reading the CLI or MIB value without using the NSP NFM-P. Including the port-desc option as part of the tx-tlv configuration allows a Nokia remote peer supporting port-desc preferred display logic to display the value in the port description TLV instead of the port-id field value. This does not change the encoding of the port-id field. The port-id field value continues to represent the ifindex. In some environments, it may be important to select the specific port information that is carried in the port-id field. The operator has the ability to control the encoding of the port-id information and the associated subtype using the port-id-subtype option. Three options are supported for the port-id-subtype:

  1. tx-if-alias — transmits the ifAlias string (subtype 1) that describes the port as stored in the IF-MIB, either a user-configured description or the default entry (that is, 10/100/Gig Ethernet SFP)
  2. tx-if-name — transmits the ifName string (subtype 5) that describes the port as stored in the IF-MIB, ifName information
  3. tx-local — the interface ifindex value (subtype 7)

IPv6 (address subtype 2) and IPv4 (address subtype 1) LLDP system management addresses are supported.

3.6. Surveillance, Control, and Data Acquisition (SCADA) Support

SCADA systems are used in many strategic industry networks, such as utility and transportation, to monitor and maintain the networks from remote monitoring locations. SCADA systems use a master/slave architecture with a single master that supports multiple slave remote terminal units (RTUs).

Nokia addresses the needs of SCADA customers with the Integrated Services card. The Integrated Services card is a resource card that is capable of supporting software applications that specifically meet the requirements of TDM-based SCADA systems. The card is supported on the 7705 SAR-8 and the 7705 SAR-18.

The Integrated Services card supports the following SCADA applications:

  1. multidrop data bridge (MDDB)
  2. pulse code modulation (PCM) multidrop bridge
  3. voice conference bridge (VCB)

Only one application can be active on the card at a time.

The MDDB and PCM multidrop bridge applications feature similar architecture and functionality, with the main exception being that the MDDB application uses a serial RS-232, RS-530, or X.21 interface, while the PCM multidrop bridge application uses an E&M analog interface. The VCB application builds on the PCM architecture, using A-Law or Mu-Law encoding and an E&M analog interface.

3.6.1. Multidrop Data Bridge

The MDDB application provides a centralized digital bridging functionality that allows a SCADA bridge to be configured between a master and remote slaves. The bridge allows a single data message stream to be broadcast from a master to multiple slaves and allows a single slave to communicate back to the master.

In a SCADA network, the 7705 SAR provides the communications infrastructure to connect the central masters to multiple RTUs at remote locations, where the masters and RTUs communicate over serial RS-232, RS-530, or X.21 links (synchronous or asynchronous). The 7705 SAR-8 or 7705 SAR-18 located at the master site contains the Integrated Services card, which provides the MDDB bridge functionality and acts as the MDDB master. Remote 7705 SAR nodes connected to RTUs are referred to as MDDB slaves.

For both master and slave applications, the 7705 SAR must be physically connected to the SCADA device by one of the following:

  1. a 7705 SAR-8 or 7705 SAR-18 using the 12-port Serial Data Interface card (supports RS-232, RS-530, and X.21 links)
  2. a 7705 SAR-H using the 4-port T1/E1 and RS-232 Combination module (supports RS-232 links only)
  3. a 7705 SAR-Hc using an on-board RS-232 serial port (supports RS-232 links only)

The 12-port Serial Data Interface card, version 1 and version 2, supports the RS-530/RS-422 interface with the use of an adapter cable that connects to a DB15 connector on the front of the X.21 distribution panel. There is no configuration specifically for the RS-530/RS-422 interface; configuration is done in X.21 mode and applies to the RS-530/RS-422 interface when it is physically enabled through hardware. The 12-port Serial Data Interface card, version 3, provides RS-530 interface capability without the need for an adapter cable. For information about 12-port Serial Data Interface card adapter cables, refer to the 7705 SAR Serial Data Interface Card Installation Guide.

The remote nodes are connected to the SCADA bridge over an IP/MPLS network.

An Integrated Services card supports up to 16 SCADA bridges. Each bridge supports 32 branches. Two branches (branch 1 and branch 2) are dedicated connections to the SCADA masters; the other 30 branches connect to the slaves. An MDDB SCADA bridge is created using the config>scada bridge-id command and a branch is created using the config>scada>branch branch-id command.

Note:

Larger bridges can be built by cascading individual bridges internally within a single Integrated Services card and using the master output from one bridge as the slave input to another bridge. Larger bridges can be cascaded across multiple Integrated Services cards by using an RS-232, RS-530, or X.21 link.

Figure 26 shows a typical SCADA MDDB network. A Cpipe SAP is configured for each master and slave branch in order to transmit data to the bridge. The RS-232/X.21 traffic is converted to a 64 kb/s Cpipe using high capacity multiplexing (HCM). The Integrated Services card terminates the Cpipe (the slaves send data back over the IP/MPLS network), recovers the data directly from the Cpipe as an HCM frame, and sends the data to the bridge.

Figure 26:  SCADA MDDB Network 

3.6.2. PCM Multidrop Bridge

The pulse code modulation (PCM) multidrop bridge application provides multidrop bridging for SCADA systems that use 4-wire analog modems to connect remote slaves to a master. Incoming analog signals from the master are converted to PCM (Mu-Law or A-Law) for transport between a remote slave and the master. The Integrated Services card broadcasts the master stream to all remote slaves. Only the addressed remote unit will respond to the broadcast and the response must be transported through the bridge back to the master via an E&M interface. If the network RTUs support two SCADA systems over the same interface by separating them into high-frequency and low-frequency bands, the PCM multidrop bridge always selects the two loudest branches to be passed through the bridge for communication with the master.

Note:

E&M signaling transport through the bridge is not supported.

Figure 27 shows a typical SCADA PCM multidrop bridge network.

Figure 27:  SCADA PCM Multidrop Bridge Network 

The PCM multidrop bridge application uses Mu-Law and A-Law encoding; therefore, the modularity is different from MDDB modularity. Table 24 shows the modularity for a PCM multidrop bridge on the Integrated Services card.

Table 24:  PCM Multidrop Bridge Modularity 

Encoding Scheme

Number of Bridges per Integrated Services Card

Number of Branches per Bridge

Total Number of Branches per Integrated Services Card

Mu-Law (North America)

16

22

352

A-Law (rest of world)

16

30

480

A PCM SCADA bridge is created using the config>scada bridge-id command and a branch is created using the config>scada>branch branch-id command.

Note:

Larger bridges can be built by cascading individual bridges internally within a single Integrated Services card and using the master output from one bridge as the slave input to another bridge. Larger bridges can be cascaded across multiple Integrated Services cards by using an E&M link.

3.6.3. Redundant Masters

The MDDB and PCM multidrop bridge applications support redundant masters, where both masters listen to all traffic that is being transmitted from the slaves but only the active master broadcasts data to the slaves.

There are two modes for master redundancy:

  1. manual (default mode)
    In manual mode, if a master branch fails, the second master branch must be made active manually with the force-active command in order to receive data from the master input. The bridge always broadcasts to both master branches.
  2. auto
    In auto mode, both master branch inputs are received simultaneously. This requires the master input behavior to be similar to an RTU; that is, only the active master transmits data and the standby master transmits either all 1s (MDDB) or no data (PCM). If the bridge is in auto mode, the force-active command cannot be used.

3.6.4. Squelch Functionality

A condition may occur where a single slave continues to send data to the master after the normal response period has expired. This condition locks up the bridge so that no other slave can transmit data back to the master. To resolve this condition, the squelch command can be enabled on a bridge or on an individual slave or master branch. Squelch is enabled by configuring a timeout period that, once expired, raises an alarm and triggers the squelching function. A normal quiescent traffic pattern (all 1s for MDDB and low volume for PCM multidrop) is inserted towards the bridge. This blocks the problematic slave so that other slaves can continue to use the bridge.

In order to put the bridge into the normal state, it must be reset. This can be manually initiated by the operator with the squelch reset command, or it can occur automatically after a configured time if the squelch-recovery command is set to auto.

For MDDB, because different algorithms are needed to detect squelch conditions at low-speed and high-speed rates, interface speed selection is required. The interface speed is set at the bridge level.

3.6.5. Voice Conference Bridge

The voice conference bridge (VCB) application provides a simultaneous communication path between two or more voice circuits. VCBs are deployed in a central location with remote devices connected to the bridge via the 7705 SAR over an IP/MPLS or TDM network. Inputs to the VCB are 4-wire E&M analog interfaces.

VCBs can be used as a conference bridge with any-to-any connectivity (all branches participate) or as a bridge in broadcast mode where one branch broadcasts to the other branches that are in listen-only mode.

The main VCB applications are:

  1. Land Mobile Radio (LMR) interconnection
    Both voice conference mode and broadcast mode can be used for this application.
  2. analog multi-terminal teleprotection interconnect for electrical utilities
    For multi-terminal teleprotection applications, VCBs allow all teleprotection relays to communicate with each other in order to make the appropriate switching decision in the event of a fault.

The VCB application uses Mu-Law and A-Law encoding, similar to PCM. Table 25 shows the modularity for a VCB on the Integrated Services card.

Table 25:  VCB Modularity 

Encoding Scheme

Number of Bridges per Integrated Services Card

Number of Branches per Bridge

Total Number of Branches per Integrated Services Card

Mu-Law (North America)

16

24

384

A-Law (rest of world)

16

32

512

A VCB SCADA bridge is created using the config>scada bridge-id command and a branch is created using the config>scada>branch branch-id command.

Note:

Larger bridges can be built by cascading individual bridges internally within a single Integrated Services card. Larger bridges can be cascaded across multiple Integrated Services cards by using an E&M link or a channel group encapsulated for cem (TDM).

3.6.5.1. VCB Applications

VCB can be configured in one of four applications. These applications are set at the card level. Each application uses a bridging algorithm that determines which branches control the management of the bridge and transmission of signals:

  1. VCB
    One branch talks and all other branches on the bridge can hear.
  2. broadcast
    Only one branch on the bridge (fixed as branch 1) has control of the bridge to transmit, and all other branches are in listen-only mode.
  3. VCB branch initiate
    Branches on the bridge are only enabled (unmuted) when the attached base station signals its presence by grounding the M-lead on the interface connected to the bridge. Upon receiving the grounded M-lead via T1/E1 ABCD bits or TDM PW signaling, the bridge unmutes the associated branch. When the ground is removed, the branch is muted again.
  4. teleprotection
    Each teleprotection relay transmits state information on discrete frequencies so that each relay can both hear what the other relays are transmitting as well as transmit its own information to the other relays.

3.6.5.2. Gain

Gain is the increase or decrease in signal power or voltage that occurs in transmitting a signal from one point to another. The two types of gain are:

  1. input
  2. output

Gain is configured at the branch level.

The input gain defines the magnitude of the increase or decrease of the signal transmitted into the bridge. The input gain range is –16 to +9 dB in 1-dB increments (the default is 0 dB).

The output gain defines the magnitude of the increase or decrease of the signal received from the bridge. The output gain range is –16 to +9 dB in 1-dB increments (the default is 0 dB).

3.6.6. Serial Transport Over Raw Sockets

Serial transport over raw sockets provides the capability of transporting serial data, in the form of characters, over an IP transport service within a Layer 3 IP/MPLS service (IES or VPRN). A raw socket allows direct sending and receiving of IP packets without any protocol-specific transport layer formatting. For information about raw socket IP transport services, refer to the 7705 SAR Services Guide, Service Overview chapter, “Raw Socket IP Transport Service”.

The feature provides the functionality for a local host to listen to and open raw socket sessions from remote hosts, and for a remote host to initiate and open raw socket sessions to local hosts. The local and remote host functions support TCP or UDP sessions (but not both concurrently) over the IP transport service.

Raw sockets are supported on the following hardware:

  1. RS-232 ports on the 12-port Serial Data Interface card, version 2 and version 3
  2. RS-232 ports on the 7705 SAR-Hc
  3. RS-232 ports on the 4-port T1/E1 and RS-232 Combination module
Note:

  1. RS-232 serial data can be carried over Cpipes or over raw sockets using IP transport. To use Cpipes, the RS-232 port must be configured with a channel ID. To use raw sockets, the RS-232 port must be configured with a socket ID.
  2. The 12-port Serial Data Interface card, version 2 and version 3, support a mix of Cpipes and raw socket serial links on the same card.

Figure 28 shows an example of a raw socket application, where serial data is transferred between RTUs and a utility’s SCADA management system using an IP transport service across a Layer 3 service (IES or VPRN), that includes 7705 SAR-H/Hc and 7705 SAR-8/18 nodes.

A raw socket local host (acting as a server) at the 7705 SAR-H/Hc substation listens to TCP sessions that originate at the 7705 SAR-8/18 central location network operations center (NOC). The 7705 SAR-8/18 at the NOC is connected to two front-end processors (FEPs), one via a serial port and another via an Ethernet port. The serial port on the 7705 SAR-8/18 is configured as a remote host (acting as a client) that initiates TCP/UDP sessions towards the RTU at the 7705 SAR-H/Hc substation when traffic is received from the FEP over the serial port. These TCP/UDP sessions are transported over the IP/MPLS network using IP transport service over an IES or VPRN service. The serial data that is transported over the TCP/UDP session and received at the 7705 SAR-H/Hc is then sent over the serial link towards the RTU. TCP/UDP sessions received from the FEP over the Ethernet port are transported over an IES or VPRN service (that is, there is no need for serial remote host configuration in this case).

Multiple FEPs can poll a single RTU. If multiple sessions attempt to transmit serial data on the serial port simultaneously, the 7705 SAR queues packets per session and ensures that all data for one session is sent out before processing another session’s data, ensuring that sessions do not overlap one another.

Note:

A serial port can be concurrently configured as both a server (local host) and a client (remote host). This is accomplished with the local-host command configuration to support the server function and the remote-host command configuration to set up client sessions to far-end remote hosts.

Figure 28:  Serial Transport Over Raw Socket Application 

3.6.6.1. Raw Socket Configuration

A raw socket IP transport interface can be configured for each RS-232 serial port on a node. This allows the serial port to receive TCP connections or UDP session packets from multiple remote hosts, or to create new sessions to remote hosts in order to send and receive serial data to and from those remote hosts.

There are port-level and service-level configuration requirements for a raw socket serial port to send and receive serial data in either server mode, client mode, or both.

Raw socket port-level configuration includes defining the end-of-packet checking parameters (idle-time, length, special character) and the inter-session delay for transmitting session data over the serial link. See Serial Commands for the required information.

At the service level, an IP transport subservice is created within an IES or VPRN service to associate the serial port with the respective IES or VPRN service. TCP/UDP encapsulated serial data is routed within the corresponding Layer 3 IES or VPRN service. The required configuration includes IP transport subservice local-host and remote-host configuration, TCP timers, and session control. Refer to the 7705 SAR Services Guide, “IES Raw Socket IP Transport Configuration Commands” and “VPRN Raw Socket IP Transport Configuration Commands” for the required information.

3.6.6.2. Raw Socket Packet Processing

Figure 29 illustrates how raw socket packets are processed over a serial link.

Session data attempting to access the serial port is queued. One queue is maintained per session. The purpose of the session queue is to prevent two different flows of packets from interleaving out the serial port and creating unreadable messages. When data is being transmitted over the serial link for a session, any other session’s data is queued until the first session has emptied its queue. The next session’s data is transmitted over the serial link only after the inter-session-delay timer expires. Each session’s data is sent out in round-robin fashion.

Figure 29:  Raw Socket Packet Processing 

3.6.6.2.1. Raw Socket Processing for UDP Sessions

When the local host receives a UDP packet from a remote host, it queues the packet and sends it over the serial link. The local host remembers the UDP session while there is still data to send from the serial link. If further packets are received for the same session, they are queued behind the already queued packet. After all the queued data has been sent over the serial link, the session is removed from the system. An associated UDP remote host for the serial link must be configured to have serial data sent back to the remote host from the serial port.

When a packet is received from the serial link based on end-of-packet (EOP) requirements, the data is copied and sent in a UDP packet to each configured remote host.

3.6.6.2.2. Raw Socket Processing for TCP Sessions

An open TCP session from a remote host to a raw socket’s local host is kept open until either the remote host terminates the session or the TCP inactivity timer expires. When a TCP session is open, all packets received from the remote host are queued for the raw socket serial link and sent over the serial link until no packets remain in the queue.

If multiple sessions are open towards the local host, and each is receiving data, each session’s data is queued and then sent over the serial link in round-robin fashion for each session until no packets remain. When a packet is received over the serial link, it is copied to each open TCP session and transmitted to the remote host.

3.6.6.3. Raw Socket Squelch Functionality

A condition may occur where the end device connected to the serial port continues to send out a continuous stream of data after the normal response period has expired. This can prevent the far-end remote host or master equipment from receiving data from other end devices in the network. To resolve this condition, the squelch command can be used on the raw socket at the port level (it is disabled by default). This stops the socket from receiving any more data from the problematic device.

If the command is enabled, the 7705 SAR will monitor the serial port for a constant character stream. A configurable squelch delay period, using the squelch-delay command, is used to determine how long to measure the constant character stream before initiating the squelch function. If the squelch function is initiated, the port is considered locked up and an alarm is raised indicating the lock-up and that the squelching function has been triggered.

The serial port can be forced out of squelch and put back to normal, either manually using the squelch-reset command or automatically using the unsquelch-delay command. The unsquelch-delay command defines the time to wait after squelch is initiated before it is removed.

3.7. Configuration Notes

The following information describes provisioning guidelines and caveats.

  1. The IOM can only be designated slot 1 of the chassis.
  2. An IOM must be preprovisioned to accept specific adapter card types; the card type is always iom-sar.
    If an adapter card type is installed in a slot provisioned for a different type, the card will not initialize.
  3. An adapter card installed in an unprovisioned slot remains administratively and operationally down until the IOM software is activated and the MDA slot and type is specified.
  4. Ports cannot be provisioned until the IOM software is activated and the MDA type is specified.

3.7.1. Reference Sources

For information on supported IETF drafts and standards as well as standard and proprietary MIBs, refer to Standards and Protocol Support.