vdocuments.net_sp420-technical-description (1).pdf

Technical Description
DESCRIPTION
1/221 02-HRA 901 21/2 Uen D

Copyright
© Ericsson AB 2013-2014. All rights reserved. No part of this document may be
reproduced in any form without the written permission of the copyright owner.
Disclaimer
The contents of this document are subject to revision without notice due to
continued progress in methodology, design and manufacturing. Ericsson shall
have no liability for any error or damage of any kind resulting from the use
of this document.
1/221 02-HRA 901 21/2 Uen D | 2014-06-23

Contents
Contents
1 Overview 1
1.1 Scope 1
1.2 Audience 1
2 Introduction 1
3 Use Cases 3
3.1 Layer 2 Solutions 3
3.2 Layer 3 Solutions 3
3.3 SP 415/420 in Other Ericsson Solutions 6
3.4 MSER Solution 8
4 System Architecture 8
4.1 Hardware Architecture 8
4.2 Ericsson IP Operating Software Architecture 10
4.3 Forwarding Abstraction Layer 20
5 Features 21
5.1 Synchronization 21
5.2 Layer 2 Features 26
5.3 TDM Circuit Emulation Service 27
5.4 Routing 32
5.5 IP Protocol Support 37
5.6 IP Services 37
5.7 Quality of Service 38
5.8 IP Performance Metrics 39
6 User Interfaces 41
6.1 Using the CLI 41
7 Administration 42
7.1 Managing Security 42
7.2 Managing Performance 44
7.3 Monitoring and Reporting Tools 44
8 Technical Specification 46
1/221 02-HRA 901 21/2 Uen D | 2014-06-23

8.1 Power Supply 46
8.2 Environmental Conditions 47
8.3 Dimensions and Weight 47
8.4 Base Platform Interface and Indicators 48
8.5 Modules 49
8.6 Cables 52
8.7 Flash Memory 57
9 Software Standard Declaration 57
10 Appendix: SFP/XFP Ethernet Interfaces 61
Glossary 83
Reference List 87
1/221 02-HRA 901 21/2 Uen D | 2014-06-23

Introduction
1 Overview
This document describes the Ericsson Smart Packet (SP) 415/420 and its
usage, services, and architecture.
1.1 Scope
This description covers the logical and functional aspects of the hardware and
software.
It includes a brief overview of the hardware architecture.
1.2 Audience
This document is intended to present an overview of the SP 415/420 platform,
including its architecture and SP 415/420 concepts, to network operators,
network and service planners, and system engineers and administrators. The
audience is expected to possess basic knowledge of telecommunications
technology.
2 Introduction
The SP 415/420 combines multiple functions into a single platform that provides
Layer 3 (IP) routing, and Layer 2 (Ethernet) network aggregation, as well as
advanced services for applications. The SP 415/420 provides carrier-class
reliability, scalability, performance, and an optimal power footprint.
The SP 415/420 platform supports the following functions:
• Comprehensive range of interior and exterior gateway routing protocols.
• Peering, edge aggregation.
• End-to-end Ethernet transport services with direct connection to the access
layer of the network.
• Traffic management with Quality of Service (QoS) and traffic shaping.
• Direct connection to the access layer of the network, which eliminates
unnecessary network layers and reduces complexity.
1
1/221 02-HRA 901 21/2 Uen D | 2014-06-23

The SP 415/420 in combination with other Ericsson products provides a
complete end-to-end solution for the following:
• IP Radio Access Network (IP RAN)—Layer 3
• Mobile Backhaul (MBH)—Layer 2 and Layer 3
For a description of these solutions, including diagrams and the configuration
requirements, see Layer 2 Solutions, Layer 3 Solutions, and SP 415/420 Router
in Other Ericsson Solutions.
Figure 1 illustrates the possible combinations and shows how other Ericsson
solutions fit with the SP 415/420 platform.
G103092A
Layer 3 Solutions
(SP 415/420)
Layer 2 Solutions
BNG Solutions
(SSR)
EPG
Layer 3
& BNG
(SSR)
Layer 2 & 3
(SP 415/420) Layer 2 & BNG
(SSR)
Converged
Figure 1 Possible Service Combinations in Evolved IP Network (EIN)
2 1/221 02-HRA 901 21/2 Uen D | 2014-06-23

Use Cases
3 Use Cases
3.1 Layer 2 Solutions
Figure 2 illustrates the SP 415/420 in a Layer 2 network.
G102995A
SP 415/420
Port
CE
PE
PE CE
Pseudowire
MPLS
Service Instances
Figure 2 SP 415/420 in a Layer 2 Network
You can use the SP 415/420 platform to provide services for Ethernet traffic.
For example:
• Layer 2 Virtual Private Networks (L2VPNs) based on Virtual Private Wire
Service (VPWS)—Provides end-to-end Layer 2 cross-connected circuits
over IP/Multiprotocol Label Switching (MPLS) core networks
• Cross-Connect VPWS-based transport, including tagged and untagged
frames as part of the VPWS (does not support MAC learning)
• Link Aggregation Groups (LAGs) provide increased bandwidth and
availability. The SP 415 supports up to 18 802.1AX link groups, and the
SP 420 supports up to 24 802.1AX link groups, both with up to eight ports
per link group.
Table 1 lists the features that you can configure for Layer 2 solutions.
Table 1 Layer 2 Solution Features
Business Application Layer 2 Transport
Method
Routing and Label Distribution
Options
Services
L2VPN VPWS L2VPN VPWS LDP or RSVP
IS-IS or OSPF
VPN pseudowire
QoS Propagation
3.2 Layer 3 Solutions
The SP 415/420 can provide Layer 3 Virtual Private Network (L3VPN) services
and IPv4 routing and transport services.
3
1/221 02-HRA 901 21/2 Uen D | 2014-06-23

3.2.1 L3VPNs
The router can provide the following Layer 3 services:
• End-to-end Layer 3 connection over an IP/MPLS core network
• Business VPNs, such as Border Gateway Protocol (BGP)/MPLS Layer
3 VPNs
• Routing solutions, such as P router and route reflector, in an IP/MPLS
network
• SP 415/420 platform in other Ericsson solutions, such as IP RAN, MBH.
• The Multiservice Edge Router (MSER) solution eliminates unnecessary
network layers and reduces complexity of the network. As an MSER, the
router can provide Layer 2 Ethernet transport services, Layer 3 unicast
routing and multicast routing, as well as broadcast TV, video-on-demand,
and VoIP services simultaneously within the same platform.
Figure 3 illustrates the router in a Layer 3 network with VPNs.
G102993A
SP 415/420 (PE)
SP 415/420 (P)
SP 415/420 (P)
SP 415/420 (PE) SSR (PE)
SP 415/420 (PE)
SSR (PE)
SP 415/420 (PE)
Figure 3 L3VPNs
3.2.2 Intra-AS Hierarchical MPLS
Intra-AS hierarchical MPLS (H-MPLS) adopts a divide-and-conquer strategy
where the core, aggregation, and access networks are partitioned in different
4 1/221 02-HRA 901 21/2 Uen D | 2014-06-23

Use Cases
MPLS/IP domains. The network segmentation among the access, aggregation,
and core domains could be based on a single AS multi-area design or a single
AS multi-instance design. In single AS multi-area and single AS multi-instance
designs, labeled iBGP unicast is used to build inter-domain LSPs. Labeled
BGP unicast is used as an inter-domain label distribution protocol to build
hierarchical LSPs across domains.
Figure 3 illustrates the router in a H-MPLS network.
G103242C
iBGP
LDP
iBGP IPv4+label
NHS NHS
NHS NHS
iBGP IPv4+label
iBGP IPv4+label
iBGP IPv4+label
iBGP IPv4+label
iBGP IPv4+label
Access
eNB
CE-PE PE
AG-BR (RR) Core-BR (RR)
Aggregation Core
iBGP
LDP
iBGP Hierarchical LSP
LDP or RSVP-TE LSP LDP or RSVP-TE LSP LDP or RSVP-TE LSP
iBGP Hierarchical LSP
LDP or RSVP-TE LSP LDP or RSVP-TE LSP LDP or RSVP-TE LSP
iBGP
LDP
eNB
NHS=Next Hop Self
Figure 4 Intra-AS Hierarchical MPLS
3.2.3 Layer 3 Solution Features
Table 2 lists the features that you can configure for Layer 3 solutions.
5
1/221 02-HRA 901 21/2 Uen D | 2014-06-23

Table 2 Configurable Features for Layer 3 Solutions
Business
Application
Circuit Options Routing Options Services
L3VPN Static circuits
(1)
Static routes or an OSPF or eBPG for
CE to PE connectivity
Combinations of the following
protocols:
BGP
MPLS
LDP or RSVP
IS-IS or OSPF
QoS
Filter ACLs
CE-PE Routing options
Route filters
Mobile applications Static circuits Combinations of the following
protocols:
BGP
MPLS
LDP or RSVP
IS-IS or OSPF
QoS
Filter ACLs
Layer 3 PE Router Static circuits CE-PE routing options:
Static
OSPF
eBGP
RIP
Routing options:
BGP
MPLS
LDP or RSVP
IS-IS or OSPF
QoS
Filter ACLs
Route Filters
ECMP
Layer 3 P Router Static circuits Routing options:
BGP
MPLS
LDP or RSVP
IS-IS or OSPF
Route Reflector
(1) Statically configured circuits, such as 802.1q PVCs.
3.3 SP 415/420 in Other Ericsson Solutions
You can also use the SP 415/420 platform in other Ericsson solutions, such
as IP RAN, or MBH.
Figure 5 illustrates the router in a topology using other solutions.
6 1/221 02-HRA 901 21/2 Uen D | 2014-06-23

Use Cases
G102994A
Access Node
SP 415/420 SP 415/420
Metro Node Metro Node
SP 415/420
Figure 5 SP 415/420 with Other Solutions
Table 3 lists the features that you can configure to use with other solutions.
Table 3 Configurable Features for Use with Other Ericsson Solutions
Business Application Access or Transport
Technologies
Routing Options Service Options or Features
SP 415/420 in IP RAN
Solution
Access types:
Direct Ethernet
Ethernet 802.1Q
Ethernet 802.1ad
Static
IS-IS, OSPF or RIP
BGP
MPLS
LDP or RSVP
QoS
Filter ACLs
BFD
LAG or ECMP
RSVP-TE Fast Reroute
SP 415/420 in MBH
Solution
Access types:
Direct Ethernet
Ethernet 802.1Q
Transport Technology:
VPWS
Ethernet 802.1ad
Static
IS-IS, OSPF or RIP
BGP
MPLS
LDP or RSVP
QoS
Filter ACLs
BFD
LAG or ECMP
RSVP-TE Fast Reroute
7
1/221 02-HRA 901 21/2 Uen D | 2014-06-23

3.4 MSER Solution
An MSER solution (see Figure 5) eliminates unnecessary network layers and
reduces complexity of the network. As an MSER, the SP 415/420 can provide
Layer 2 Ethernet transport services, and Layer 3 unicast routing, as well as
broadcast TV, video-on-demand, and VoIP services simultaneously within
the same platform.
With the configured services listed in Table 4, the high-capacity SP 415/420
supports mobile and fixed backhaul traffic, with a full range of services. It also
supports enterprise VPN connections and end-to-end Layer 3 connection over
an IP/MPLS core network.
Table 4 Configurable Features for Use with Other Ericsson Solutions
Business
Application
Access or Transport
Technologies
Infrastructure
Protocols
Service Protocols Service Options or
Features
Converged Backhaul Access types:
Direct Ethernet
Ethernet 802.1Q
Transport Technology:
VPWS
Static
IS-IS, OSPF or RIP
MP-BGP
MPLS
LDP or RSVP
T-LDP
Static
BGP
OSPF
L3VPN (CE-PE)
Inter-AS VPN
QoS
Filter ACLs
BFD
LAG or ECMP
IP Multicast
4 System Architecture
4.1 Hardware Architecture
SP 415 and SP 420 are introduced in this document. For more information, see
Section 8 on page 46.
8 1/221 02-HRA 901 21/2 Uen D | 2014-06-23

System Architecture
SP 415
36 Gbps uni-directional (72 Gbps bidirectional) full-duplex switching capacity,
1.5 U height with 16 multi-speed Gigabit Ethernet (GE) SFP ports (8 combo
ports), two 10GE XFP ports on expansion modules.
G102913A
PSU
USB GE TX ports GE SFP ports Air filter
Console
Sync Expansion module Fan tray
Management
Slot Numbering
1
5 2
3
4
6
SP 415
Figure 6 SP 415 Overview
SP 420
60 Gbps uni-directional full-duplex switching capacity, 1.5 U height with 20
multi-speed GE SFP ports (8 combo ports), two 10GE XFP ports on front panel
and two 10GE XFP ports on expansion modules.
21
G102914A
PSU
USB GE TX ports GE SFP ports
10GE XFP ports
Air filter
Console
Sync Expansion module Fan tray
Management
Slot Numbering
1
5 2
3
4
6
SP 420
Figure 7 SP 420 Overview
Note:
• The SP 415/420 supports two CES cards to coexist on slot 2 and
slot 3.
• The 10GE expansion module is not supported in SP 415/420 14B.
9
1/221 02-HRA 901 21/2 Uen D | 2014-06-23

4.2 Ericsson IP Operating Software Architecture
This section describes the Ericsson IP Operating System as implemented on
the SP 415/420 platform.
4.2.1 Software Components
Figure 8 illustrates the Ericsson IP Operating System major software
component relationships.
G102992A
Router
Router
Router
10 GE Port
context:
local
context:
isp
binding
binding interface: if2
interface: if1
binding
interface: if3
GE Port
GE Port
Figure 8 SP 415/420 Software Component Interrelationships
4.2.1.1 Contexts
Most networking products are designed so that the entire set of ports, circuits,
and protocols operate together as one global router. However, the SP 415/420
supports multiple contexts, which act as virtual routers running within a single
physical device. A context operates as a separate routing and administrative
domain, with separate routing protocol instances, addressing, authentication,
accounting, and so on. A context does not share its information with other
contexts.
Separating the contexts allows you to separate services and provide direct
access and different classes of services for customers. You use a single
physical device, with one or more contexts assigned to each service provider or
service class. Implementing this type of topology with equipment from other
vendors would require multiple devices.
4.2.1.2 Interfaces
The concept of an interface on the SP 415/420 differs from earlier networking
devices. In earlier devices, the term interface is often used synonymously with
port, channel, or circuit, which are physical entities. In the SP 415/420, an
10 1/221 02-HRA 901 21/2 Uen D | 2014-06-23

System Architecture
interface is a logical construct that provides higher layer protocol and service
information, such as Layer 3 addressing. Interfaces are configured as part of
a context and are independent of physical ports and circuits. The decoupling
of the interface from the physical layer entities enables many of the advanced
features offered by the router.
For the higher layer protocols to become active, an interface must be
associated—or bound—to a physical port or circuit. For more information about
bindings, see Section 4.2.1.4 on page 11.
4.2.1.3 Ports and Circuits
Ports and circuits in the router represent the physical connectors and paths on
the SP 415/420 line cards and controller cards. In general telecommunications
use, a circuit is a communications path between two or more points. In
an SP 415/420, the term circuit refers to the endpoint of a segment of a
communications path that terminates on the router.
You configure hardware and software parameters to specify the behavior of the
port or circuit for a particular router.
The SP 415/420 supports two types of circuits:
• Non-transport Ethernet circuits, which can include static 802.1Q PVCs
and 802.1Q tunnels.
• Layer 2 service instances (SIs), which are subinterfaces of a LAN that
accept one or more Layer 2 (802.1Q) services for transport across local
physical ports or a provider backbone network. You can create and
configure one or a range of Layer 2 service instances on any Ethernet
port, except on the management port.
For more information, see Ethernet Ports, Ethernet Circuits, and Layer 2
Service Instances.
4.2.1.4 Bindings
Bindings associate particular ports or circuits with the higher layer routing
protocols configured for a context. No user data can flow on a port or circuit
until a higher layer service is configured and associated with it. After a port or
circuit is bound to an interface, traffic flows through the context as it would
through any IP router.
Bindings are statically mapped. You can bind multiple ports and circuits to a
single interface.
For more information, see Bindings.
Dynamic binding occurs when a circuit is bound to the higher-layer protocols
based on session information.
11
1/221 02-HRA 901 21/2 Uen D | 2014-06-23

4.2.2 Software Processes
Figure 9 illustrates the Ericsson IP Operating System architecture.
This section provides definitions of the SP 415/420 processes illustrated.
uBoot
MPLS Routing
Security Application Suite
DHCP
LG CES TWAMP SyncE PTP NTP
LDP
MPLS-Static
Multicast Manager
RSVP
CSPF
OSPF
BGP
ISIS
AAA
TACACS+
RADIUS
RIP
Static
Multicast
PIM
IGMP
Sysmon PM STATd Logger CSM RCM
ARP PEM SNMP PING PAD Dot1Q
Linux Kernel
Security
System
Infrastructure
LM ISM RIB CLS QoS FLOW
Services
Forwarding
Applications
G103091D
Figure 9 SP 415/420 Software Architecture
12 1/221 02-HRA 901 21/2 Uen D | 2014-06-23

System Architecture
4.2.2.1 Independent System Processes
Because the major software components act as independent processes, a
process can be stopped, restarted, and upgraded without reloading the entire
system or individual traffic cards. In addition, if a single component fails or is
disrupted, the system continues to operate.
Separating the route processing and control functions from the forwarding
function also provides the following benefits.
• Dedicated route processing functions are not affected by heavy traffic.
• Dedicated packet forwarding is not affected by routing instability in the
network.
• The architecture enables line-rate forwarding on all traffic ports.
• You can add new features to the control software on the controller without
affecting forwarding performance.
4.2.2.1.1 Platform Management Processes
SP 415/420 major system components run as separate processes. Table 5
lists some examples.
Table 5 Ericsson IP Operating System Processes
Module Descriptions
Card/Port State Module
(CSM)
Processes events for cards and ports, and relays events to other
processes, such as RCM, ISM, PM, and the kernel.
Interface and Circuit
State Manager (ISM)
Monitors and disseminates the state of all interfaces, ports, and
circuits in the system.
Logger Manages logging
Platform Administration
Daemon (PAd)
Monitors and configures platform entities, such as ports and cards.
It interacts with components to ensure that cards are configured
properly and brought up and down following configurations, and that
ports are activated and monitored for correct operation.
Port Encapsulation
Module (PEM)
IP Operating System process that controls port-specific packet
encapsulation used in the forwarding plane.
Ping Runs Ping operations on the SP 415/420.
Process Manager (PM) Monitors and controls the operation of the other processes in the
system.
Router Configuration
Module (RCM)
Controls all system configurations using a transaction-oriented
database.
Simple Network
Management Protocol
(SNMP)
Performs monitoring and management of network devices.
Communicates trap and Inform-Request and manages requests
according to the Management Information Bases (MIBs).
13
1/221 02-HRA 901 21/2 Uen D | 2014-06-23

Table 5 Ericsson IP Operating System Processes
Module Descriptions
Statistics Manager
(statd)
Maintains counters from the forwarding plane, aggregates, and
processes counters, and allows various applications in the system,
including the command-line interface (CLI), to access the counters.
System Monitor
(Sysmon)
Manages system event messages.
4.2.2.2 Layer 2 Processes
4.2.2.2.1 ARP Process
The Address Resolution Protocol (ARP) process manages IP-to-MAC address
resolution, as described by RFC 826. IP ARP and XC ARP are supported. ARP
entries are stored in a database residing on the control plane. XC ARP is used
for cross-connects to manage MAC information for the Layer 2 portions of
the bypass connection.
4.2.2.2.2 DOT1Q Process
The dot1q (802.1Q) process manages circuits with 802.1Q single and
double-tagged encapsulation. These include explicitly configured circuits and
circuit ranges, as well as circuits created on demand. For double-tagged
packets, a circuit corresponds to both tags or to just the outer tag (a tunnel).
4.2.2.2.3 LG Process
Link Group daemon (LGd) is responsible for link aggregation and running the
Link Aggregation Control Protocol (LACP).
4.2.2.3 User Access Processes
User access functions are managed by modules such as the following:
4.2.2.3.1 AAA Process
The AAA process performs Authentication, and Authorization of administrators,
subscribers, tunnels, and circuits, and performs the following tasks:
• In collaboration with other processes, provisions, manages, and retains
subscriber sessions.
• Implements AAA configuration and command processing.
• Handles RADIUS and communicates with RADIUS servers.
Note: The AAA accounting service is not being supported currently.
14 1/221 02-HRA 901 21/2 Uen D | 2014-06-23

System Architecture
4.2.2.3.2 DHCP Process
DHCP passes configuration information to hosts on a Transmission Control
Protocol/Internet Protocol (TCP/IP) network. DHCP is based on the Bootstrap
Protocol (BOOTP), adding the capability of automatic collection of reusable
network addresses and more configuration options.
The SP 415/420 router supports external DHCP relay server. In relay mode, the
router acts as an intermediary between the DHCP server and the subscriber.
The router forwards requests from the subscriber system to the DHCP server
and relays the server responses back to the subscriber system.
4.2.2.3.3 RADIUS Process
The RADIUS process manages configuration of RADIUS attributes, and SP
415/420 interactions with RADIUS servers.
4.2.2.3.4 TACACS+ Process
The Terminal Access Controller Access-Control System Plus (TACACS+)
process manages configuration of TACACS+ attributes, and SP 415/420
interactions with TACACS+ servers.
4.2.2.4 Feature Processes
4.2.2.4.1 QoS Process
The QoS process provides different priorities to different applications, users, or
data flows and enforces forwarding throughput limits in individual data flows
and aggregations of flows. It also implements related Resource Reservation
Protocol (RSVP) mechanisms and configures forwarding that implements QoS.
4.2.2.4.2 TWAMP Process
The Two-Way Active Measurement Protocol (TWAMP) process measures
round-trip network performance between any two devices that support the
TWAMP protocols.
4.2.2.4.3 SyncE Process
The Synchronous Ethernet (SyncE) process manages configuration of SyncE
attributes.
4.2.2.4.4 PTP Process
The Precision Time Protocol (PTP) process performs the PTP protocol
functions, including providing time alignment and clock recovery, and handling
PTP configuration, show, and debug commands. SP 415/420 can be used as
15
1/221 02-HRA 901 21/2 Uen D | 2014-06-23

an Ordinary Clock (OC), or a Boundary Clock (BC), to receive clocking from
another PTP-enabled device, or to provide clocking to a PTP-enabled device.
4.2.2.4.5 NTP Process
The Network Time Protocol (NTP) process performs the NTP protocol functions,
including synchronizing the system time with NTP server, and handling NTP
configuration, show, and debug commands.
4.2.2.4.6 CES Process
The Circuit Emulation Service (CES) process manages the configuration of
CES module to allow Packet Switched Network (PSN) to access Time Division
Multiplexing (TDM) services and to transmit TDM data transparently.
4.2.2.4.7 CLS Process
The Classifier (CLS) module manages access control lists (ACLs), including
processing ACL-related configurations and generating the information
necessary to program the specialized hardware that implements the ACLs in
the forwarding plane.
4.2.2.5 Routing Processes
In the Ericsson IP Operating System, route information is collected from the
different routing protocols in the Routing Information Base (RIB) on the system
controller card, which calculates the best routes and downloads them to the FIB.
G102991B
OSPF
RIP
Figure 10 Routing Information Flow
16 1/221 02-HRA 901 21/2 Uen D | 2014-06-23

System Architecture
4.2.2.5.1 RIP Process
The Routing Information Protocol (RIP) process implements RIP Version 2
(RFC 1388). It also implements RIPv2 over a multibind interface, which is
a proprietary feature.
4.2.2.5.2 BGP Process
The BGP process is responsible for installing routes in the RIB, and
communicating MPLS labels allocated by BGP to the Label Manager (LM).
4.2.2.5.3 IS-IS Process
The Intermediate System-to-Intermediate System (IS-IS) process performs
the IS-IS routing protocol functions, including providing routes to the RIB and
handling IS-IS configuration, show, and debug commands. It also responds to
events on interfaces where it is running.
4.2.2.5.4 OSPF Process
The Open Shortest Path First (OSPF) performs the OSPF routing protocol
functions, including providing routes to the RIB and handling OSPF
configuration, show, and debug commands. It also responds to events on
interfaces where it is running.
4.2.2.5.5 RIB Process
The RIB process runs on the system controller card. It is a fundamental
router process that directly impacts how packets flow in and out of the box. It
configures the routing tables in the forwarding plane and connectivity to the
management interface. The RIB process collects routes from its clients, selects
the best path, and downloads the routes to the FIB. See Figure 10 for a diagram
of RIB-related information flow and some of the modules that it interacts with.
4.2.2.5.6 Staticd Process
The Static daemon (Staticd) supports both interface (connected) and gateway
(non-connected) IP static routes that can be configured either through CLI.
4.2.2.5.7 Multicast Process
The multicast process (Multicast Manager) collects multicast groups and
forwarding data from the PIM and Internet Group Management Protocol (IGMP)
processes and passes it to the Multicast FIB (MFIB). It also logs multicast
events.
17
1/221 02-HRA 901 21/2 Uen D | 2014-06-23

PIM IGMP
MFIB
Multicast Manager
G103255A
Figure 11 Multicast Information Flow
The IGMP process manages IGMPv3, as described in RFC 3376, and IGMPv2,
as described in RFC 2236. On SP 415/420 interfaces, the process determines
which IP multicast groups and, for IGMPv3, which sources have listeners on
the network attached to the interface. Collected information is provided to PIM
to be advertised to other multicast routers.
The PIM process maintains multicast information per group and per interface,
which is downloaded to the Multicast Manager.
4.2.2.5.8 MPLS Process
The MPLS process enables MPLS forwarding by downloading the
Label-Switched Path (LSP) configuration to the Label FIB (LFIB).
18 1/221 02-HRA 901 21/2 Uen D | 2014-06-23

System Architecture
IGP Routes
LDP Static MPLS BGP
RSVP
RIB
(MPLS Routes)
LM
LFIB
G103236A
FIB
Figure 12 MPLS Label Information Flow
4.2.2.5.9 LM Process
The Label Manager (LM) process manages label requests and reservations
from various MPLS protocols, such as Label Distribution Protocol (LDP) and
RSVP, and configures LSPs and PWs in the system. It installs LSPs and
Layer 2 routes in the RIB and provisions MPLS-related data structures in the
forwarding plane. It also handles MPLS-related configurations and functionality,
such as MPLS ping and traceroute. L2VPN functionality is handled in the LM
process, including configuration and pseudowire setup.
4.2.2.5.10 LDP Process
The LDP process creates MPLS labels based on OSPF and IS-IS routes. It
installs LSPs in the LM and registers labels, routes, and prefixes in the RIB.
The Update process sends LDP updates to neighbors.
4.2.2.5.11 RSVP Process
The RSVP process implements RSVP (as described in RFC 3031, RFC 3032,
RFC 3209, and RFC 4090), providing LSPs to the LM process. It queries the
RIB for outgoing interfaces and next-hop information and registers Bidirectional
Forwarding Detection (BFD) sessions in the RIB.
4.2.2.5.12 MPLS-Static Process
The MPLS-Static process manages the static LSP configuration on the router,
when serving as an Ingress Label Edge Router (iLER), a Label-Switching
19
1/221 02-HRA 901 21/2 Uen D | 2014-06-23

Router (LSR), or egress LER (eLER), and communicates the details to the
LM process.
4.3 Forwarding Abstraction Layer
The SP 415/420 has a common Forwarding Abstraction Layer (FABL) that
enables deliver new features across different platforms (other IPOS products),
without having to do and maintain major work in the upper layers, which results
in IPOS being more stable.
The SP 415/420 support the following forwarding types:
• Unicast flow—The forwarding process performs packet processing
functions, such as FIB lookup for the longest prefix match with the
destination IP address, and QoS classification for fast data traffic and
slower control traffic, such as Internet Control Message Protocol (ICMP), or
BFD messages.
• Multicast flow—An application multicast group associates each multicast
packet with a set of outgoing circuits.
Figure 13 illustrates the common SP 415/420 forwarding adaptation layer
architecture.
20 1/221 02-HRA 901 21/2 Uen D | 2014-06-23

Features
G103093A
Linux Kemel - System Controller Card
Forwarding Subsystem
(FABL)
Process Manager
(PM)
Forwarding Databases
(FIB, LFIB)
Application Layer
Daemon(ALD)
Switch Chip
(ASIC)
Card Monitoring
Subsystem
To/From Network
Figure 13 SP 415/420 Forwarding Architecture
5 Features
5.1 Synchronization
5.1.1 Synchronization Overview
Following figure shows how the selection mechanism of SP 415/420 works to
provide the clock source to the internal system clock (equipment clock):
21
1/221 02-HRA 901 21/2 Uen D | 2014-06-23

G102988A
PTP
Sync E
E1/T1
CES
Card
SYNC IO
working
protection
up to 4 clocks, 25 M
Selector
A
.
.
. Selector
B
Holdoff/
WTR
T0 Internal
Clock
Distribution
8 kHz
up to 2 clocks
for each card,
2.048 M/1.544 M
1PPS up to 8
clocks
Figure 14 Clock Management Mechanism Overview
Note: 1 PPS is driven by the Precision Time Protocol and it is one candidate
of the Clock Source.
SP 415/420 traces to the new reference when clock source is lost and new
clock sources are available. SP 415/420 locks to a new source within about 2
minutes (depends on the clock quality). During the locking period, the clock and
phase are gradually adjusted.
The following synchronization sources are supported in SP 415/420:
• Based on packet
Precision Time Protocol (PTP).
NTP Client
• Others:
Sync IO (ToD1PPS port).
Sync from CES PDH Port.
Synchronous Ethernet.
5.1.1.1 Functional Requirements
• SP 415/420 conforms to ETSI ETS 300 417-6-1 regarding requirements
specified for a SEC device.
• SP 415/420 conforms to ITU-T G.8261, ITU-T G.8262, and ITU-T G.8264
for EEC device.
• SP 415/420 conforms to ITU-T Recommendation G.781.
22 1/221 02-HRA 901 21/2 Uen D | 2014-06-23

Features
• SP 415/420 conforms to IEEE Standard 1588™-2008.
• SP 415/420 conforms to RFC 1305 Network Time Protocol (Version 3).
5.1.1.2 Functional Model
The model in the following figure illustrates the internal SP 415/420
synchronization select process.
G102974A
ETY => TE
PDH => T2
Sync IO
Equipment
clock =>
Inputs Outputs
slot/port
PTP
Priority QL
Prio.:3 QL
Prio.:4 QL
Prio.:1 QL
Prio.:2 QL
slot/port
slot/port
slot/port
Figure 15 SP 415/420 Synchronization Select Process in QL-Enabled Mode
G102975A
Inputs Outputs
Priority:3
PTP slot/port
slot/port
slot/port
Priority:4
ETY => TE slot/port
slot/port
slot/port
Priority:1
PDH => T2 slot/port
slot/port
slot/port
Priority:2
Sync IO slot/port
slot/port
slot/port
Equipment clock =>
Priority
Figure 16 SP 415/420 Synchronization Select Process in QL-Disabled Mode
T2, TE in the preceding figure represent reference timing provided by the
CESPDH and Sync Ethernet traffic interface. The configurable value for Quality
Level (QL) is introduced in Section 5.1.1.3 on page 24. SP 415/420 supports
23
1/221 02-HRA 901 21/2 Uen D | 2014-06-23

the equipment clock automatically switch on the condition of synchronous
signal source failure.
SP 415/420 contains an equipment clock synchronization selection process,
operating in either QLenabled or QL-disabled mode. The process is responsible
for selecting the best signal source to be used as reference input for the PLL,
generating the equipment clock. The selection is done among a number
of nominated sources (within the signal types PTP, T2, TE, and sync IO)
based on their priority (QL-disabled mode) or QL and priority (QL-enabled
mode) as configured by the network operator. In the free-running mode, the
equipment clock complies with the clock requirements as described in ITUT
Recommendation G.8262. When operating in the locked mode, the equipment
clock is aligned to the selected reference source. This frequency in turn applies
to Ethernet signals and PDH signals (going out from the NE).
5.1.1.3 QL Support
SP 415/420 supports Ethernet synchronization messaging channel (ESMC) to
transmit and receive configurable Synchronization Status Messages (SSM).
This function is used in QL-enabled mode. SP 415/420 supports ESMC on all
the Ethernet traffic interfaces. When the peer side does not support ESMC, an
administrative configured QL can be used.
SP 415/420 supports QL in Option I and Option II mode as defined in G.781.
When Option II mode is configured, equipment clock is running in the second
generation of SSM. However, first generation of SSM can be configured for
synchronization enabled Ethernet port.
5.1.1.4 Synchronization Input Validation and Monitoring
The selected equipment clock synchronization source is validated before it is
used to synchronize the internal clock. The synchronization source is also
monitored after it is accepted. If the frequency is found to be out of range based
on the requirement of EEC, this source is set failed and an alarm is sent. It also
triggers the synchronization software to provide the timing source reselection.
5.1.2 Precision Time Protocol
SP 415/420 supports Precision Time Protocol (PTP) clocking, and
clock recovery, based on IEEE 1588-2008. PTP supports system-wide
synchronization accuracy in the submicrosecond range with minimal network
and local clock computing resources. It is applicable to distribute systems
consisting of one or more nodes, communicating over a network. SP 415/420 is
used as an Ordinary Clock (OC), or a Boundary Clock (BC), to receive clocking
from another PTP-enabled device, or to provide clocking to a PTP-enabled
device. PTP in SP 415/420 supports two-step clock when the NE works as
master, supports one-step clock, and two-step clock when the NE works as
slave.
24 1/221 02-HRA 901 21/2 Uen D | 2014-06-23

Features
OC supports Ethernet multicast encapsulation that delivers frequency to
downstream devices over physical layer, such as SyncE or ToD1PPS.
SyncE
OC
SP 415 SP 415 Time Provider
G102977A
No 1588 BC
Figure 17 SP 415/420 Delivers Frequency to Base Station through Physical
Layer
BC supports Ethernet multicast encapsulation. Both Frequency and
Phase/Time information are delivered to downstream devices through IEEE
1588, as shown in Figure 18.
1588
BC
SP 415 SP 415 Time Provider
G102978A
No 1588 BC
Figure 18 SP 415/420 Delivers Frequency and Phase to Base Station
through IEEE 1588
SP 415/420 supports end-to-end synchronization mechanism.
5.1.3 Sync IO
Sync IO has two interfaces, which make protection for each other. The two
interfaces support 1PPS output mode in SP 415/420.
PTP clock works as a slave and generates time and phase to drive the Sync
IO ports.
5.1.4 NTP Client
SP 415/420 system can work as an NTP client to get the system time from
NTP server. The system time changes from synchronizing with NTP server to
synchronizing with PTP clock automatically when PTP state is time locked.
25
1/221 02-HRA 901 21/2 Uen D | 2014-06-23

Note: When the NTP is enabled, the date and (or) time can be set by the
command, but the NTP protocol updates the time as soon as the NTP
server is connected.
NTP protocol accuracy is for time stamp events and logs.
SP 415/420 can work as NTP client of version 3.
The IP address of the NTP server needs to be configured. SP 415/420 supports
the operator to configure the system time and date when the NTP client is
disabled.
5.2 Layer 2 Features
5.2.1 Link Aggregation Groups
The SP 415/420 supports LAGs based on the IEEE standard Link Aggregation
Group (LAG) 802.1AX. LAG 802.1AX (2008) is the current version of LAG
802.3ad (2000).
The Ericsson IP Operating System supports a unified LAG model, where a link
group can consist of a mix of circuits configured for packet-based hashing
(where load balancing is done per flow based on a hash algorithm). Link groups
also support fast failover, as well as the QoS policing and queueing features.
Whereas the QoS configuration for link groups is done at the link-group level
(link group configuration mode), policing and queueing are performed internally
per constituent port. The SP 415 supports up to 18 802.1AX link groups,
and the SP 420 supports up to 24 802.1AX link groups, both with up to eight
ports per link group. Link groups provide increased bandwidth and availability.
Load balancing and load distribution over the ports in the link group result in
increased bandwidth. In addition, when ports are bundled in a link group, the
failure or replacement of one link in the group does not cause the link group to
be brought down. Instead, other links accept the traffic of the link that is out of
service, with the following process:
• Single-port link group—Migrating services from one slot to another without
impacting services by first adding the new constituent port to the link group
and removing the old port from the link group.
• Link redundancy—Using a link group with two ports to provide link
redundancy.
• Additional link capacity—Using a link group with N ports to carry traffic.
For more information on LAG, see Link Aggregation Groups.
26 1/221 02-HRA 901 21/2 Uen D | 2014-06-23

Features
5.3 TDM Circuit Emulation Service
SP 415/420 provides an optional CES module to allow Packet Switched
Network (PSN) to access Time Division Multiplexing (TDM) services and to
transmit TDM data transparently.
Pseudo-Wire (PW) is a mechanism that carries the essential elements of
an emulated service from a PE to another one or more PEs over a PSN. It
emulates a variety of services (such as TDM) through a tunnel (such as IP) over
a PSN. PSN can transmit the data payload of diversified services. The internal
data service carried by a PW is invisible to the core network. In other words,
the core network is transparent to the CE data streams.
As shown in the figure below, a local Attachment Circuit (AC) and a remote
AC are connected by a PW which is a visual connection for CES between
Provider Edges (PE). In SP 415/420, the E1/DS1 or the channel bundle is
the AC interface.
Bundling
IP
SP 415/420 SP 415/420
E1/DS1
Bundling
E1/DS1
BSC/RNC
BTS/NodeB
G103256A
Figure 19 CES Overview
The local PE cut the TDM bit stream into blocks and encapsulates them in
frames. The frames are forwarded to the remote PE which decapsulates the
frames and restores the original bit stream.
5.3.1 CES Encapsulation
SP 415/420 supports the following encapsulation formats for TDM over Packet
(TDMoP) connection:
• TDM over UDP/IP Encapsulation
SP 415/420 supports both structure aware and structure agnostic CES modes.
SP 415/420 supports the latest Structure-Agnostic TDM over Packet (SAToP)
standard (RFC 4553) for unstructured E1/DS1 traffic.
SAToP describes a method for encapsulating TDM bit-streams (DS1, E1, E3
and T3). It addresses only structure-agnostic transport, such as unframed
E1, DS1, E3 and T3. It segments all TDM services as bit streams and then
encapsulates them for transmission over a PW tunnel. This protocol can
transparently transmit TDM traffic data and synchronous timing information.
27
1/221 02-HRA 901 21/2 Uen D | 2014-06-23

SAToP completely disregards any structure and PEs have no need to interpret
the TDM data or to participate in the TDM signaling. The protocol is a simple
way for transparent transmission of PDH bit-streams.
SP 415/420 only supports DS1/E1 and does not support T3/E3.
SAToP defines three encapsulation modes for outer layer tunnel of PWs:
IP/UDP, L2TPv3 and MPLS.
SP 415/420 only supports IPv4/UDP encapsulation mode and does not support
L2TPv3 and MPLS encapsulation mode for outer layer tunnel for SAToP.
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 1 2 3 4 5 6 7 8 9 0 1
IPv4/IPv6 and UDP (PW demultiplexing layer) headers
OPTIONAL
Fixed RTP Header (see [RFC3550])
SAToP Control Word
TDM data (Payload)
G101108A
...
...
...
...
0 1 2 3
Figure 20 SAToP Packet Format for an IPv4/IPv6 PSN with UDP PW
Demultiplexing
SP 415/420 supports the circuit emulation of structured E1/DS1 traffic (CES
over PSN according to RFC 5086) as well.
Compared to SAToP, CESoPSN transmits emulated structured (NxDS0) Time
Division Multiplexed (TDM) signals. That is, it can identify and process the
frame structure and transmit signaling in TDM frames. Structured E1, for
example, comprises 32 timeslots. Except slot 0, each of the other 31 timeslots
carries a line of 64 kbps voice service. Timeslot 0 transmits signaling and frame
delimiters. The CESoPSN protocol can identify frame structure of TDM service.
It may not transmit idle timeslot channels, but only extracts useful timeslots of
CE devices from the E1 traffic stream and then encapsulates them into PW
packets for transmission.
Likewise, the CESoPSN solution provides three encapsulation modes for outer
layer tunnels of PWs: IP/UDP, L2TPv3 and MPLS. Unlike SAToP, CESoPSN
carries TDM traffic data in a frame structure inside PWs and addresss an M
field to the PW control word in a PW packet to identify the signaling check at
the side of some ACs.
28 1/221 02-HRA 901 21/2 Uen D | 2014-06-23

Features
SP 415/420 only supports IPv4/UDP encapsulation mode and does not support
L2TPv3 and MPLS encapsulation mode for outer layer tunnel for CESoPSN.
5.3.2 TDM interface
SP 415/420 supports E1 or DS1 as a TDM interface.
The interface can generate the following alarms:
• Alarm Indication Signal (AIS)
• Receive loss of signal (LOS)
• Receive loss of frame (LOF)
• Remote Alarm Indication (RAI)
For E1/DS1 TDM interface, many attributes are configured, such as:
• Frame type
• Line code
• Clock source
• Loopback
5.3.3 Interworking Function and attributes
Interworking Function (IWF) describes the functional block that segments and
encapsulates TDM into SAToP/CESoPSN packets and that in the reverse
direction decapsulates SAToP/CESoPSN packets and reconstitutes TDM. SP
415/420 supports a maximum of 64 IWFs.
BTS/NodeB
PWE3 IW
Function
PWE3 IW
Function
IP
E1/DS1
E1/DS1
BSC/RNC
G103257A
Figure 21 PW IWF
Once the PW is set up, TDM data is packetized by the PSN-bound IWF using
the configured number of payload bytes per packet and transmit the packets
over the PSN. The CE-bound IWF includes a jitter buffer where payload of the
received packets is stored prior to play-out to the local TDM attachment circuit.
29
1/221 02-HRA 901 21/2 Uen D | 2014-06-23

The size of this buffer should be locally configurable to allow accommodation to
the PSN-specific packet delay variation.
In order to set up a PW between two PE devices, a consistent payload size
should be configured in both ends. For both CESoPSN and SAToP modes,
payload size is configured by setting the latency.
Configuring the jitter buffer parameters correctly avoids under-run and overrun
situations. Under-run occurs when the jitter buffer is empty (the entering rate is
lower than the exiting one). In case of an under-run event, the chip transmits
conditioning data instead of actual data towards the TDM interface. Overrun
occurs when the jitter buffer is full and there is no room for new data to enter
(the entering rate exceeds the exiting one). Under-run and overrun require a
special treatment from the chip, depending on the bundle type.
5.3.4 Clock Recovery Mechanism
For CES, both sides of the PW need one common frequency. ITU G.823, ITU
G.824, and ITU G.8261 are supported in SP 415/420.
The TDMoP supports three clock recovery methods as described in the
following:
• Recovery From Line
The E1/DS1 interface has the ability to recover the clock from the physical
line. If both sides of the PW recover the clock from the line, CES does not
recover the clock from the PS domain. The figure below shows an example
of clock recovery from line.
Customer
Edge
Customer
Edge
Common
Reference Clock
Packet
Switched
Network
G103258A
E1/DS1 E1/DS1
SP 415/420 SP 415/420
Figure 22 E1 /DS1 Clock Recovered from Line
• Recovery From Local Clock
The E1/DS1 interface can use a local system clock. If both sides of the
PW use a common reference clock, then CES does not need to recover
30 1/221 02-HRA 901 21/2 Uen D | 2014-06-23

Features
the clock from the PS domain. The common clock can be provided by a
clock network or the GPS. The figure below shows an example of using
local clock.
Customer
Edge
Customer
Edge
Common
Reference Clock
Packet
Switched
Network
G103259A
E1/DS1 E1/DS1
SP 415/420 SP 415/420
Figure 23 E1/DS1 Using Local Clock
• Recovery From Incoming Packet
The E1/DS1 interface has the ability to recover the clock from the incoming
packet. Adaptive mode is supported by SP415/420. The adaptive mode
can be used if two sides of PW do not have a common clock and their clock
is run locally. Figure 24 shows an example of adaptive mode.
Note: Adaptive clock recovery utilizes only observable characteristics
of the packets arriving from the PSN. The recovered clock
performance depends on packet network characteristics.
Customer
Edge
Customer
Edge
Common
Reference Clock
Packet
Switched
Network
G103260A
E1/DS1 E1/DS1
SP 415/420 SP 415/420
Adaptive Clock Recovery
Figure 24 Adaptive Mode of Clock Recovery
31
1/221 02-HRA 901 21/2 Uen D | 2014-06-23

5.4 Routing
The SP 415/420 supports standard IP routing that forwards packets to their
final destination using intermediate nodes. Each node looks up the destination
IP address and forwards the packet toward the destination through routes
collected in a routing table.
On the SP 415/420, route information is collected from the different routing
protocols in the RIB on the system controller card, which calculates the best
routes and downloads them to the FIB. The RIB process collects routes to
directly attached devices, configured static IP routes, and routes learned
dynamically from RIP, OSPF, BGP, and IS-IS.
When a network event causes routes to go down or become unavailable,
routers distribute routing update messages that are propagated across
networks, causing a recalculation of optimal routes. Routing algorithms
that converge slowly can cause routing loops or network outages. Many
algorithms can quickly select next-best paths and adapt to changes in the
network topology. Because the SP 415/420 control and forwarding planes are
separated, the SP 415/420 continues to forward traffic during this process.
5.4.1 Routing Protocol Support
The SP 415/420 supports the following routing protocols:
• Basic IP Routing
Basic IP routing on the SP 415/420 includes static IP routing, IP Martian
addresses, and maximum IP routes. For more information, see IP Routing.
• RIP
RIP is a distance-vector protocol that uses hop count as its metric. It can
be used in small, homogeneous networks. The router supports RIPv2
and provides for multiple RIP instances. Each instance maintains its own
routing table and set of interfaces. Each interface can be assigned to only
one RIP instance.
For more information, see RIP.
• OSPF
OSPF is an Interior Gateway Protocol (IGP) that uses link-state
advertisements (LSAs) to inform other routers of the state of the sender
links. In a link-state routing protocol, each router distributes information
about its interfaces and neighbor relationships. The collection of the link
states forms a database that describes the autonomous system (AS)
topology. As OSPF routers accumulate link-state information, they use the
Shortest Path First (SPF) algorithm to calculate the shortest path to each
node, which forms the basis for developing routing information for that AS.
32 1/221 02-HRA 901 21/2 Uen D | 2014-06-23

Features
The router supports OSPFV2.
For more information, see OSPF.
• BFD
The router supports RFC 5880, BFD, and RFC 5881, BFD for IPv4. BFD is
a simple Hello protocol that is similar to the detection components of some
routing protocols. A pair of routers periodically transmits BFD packets
over each path between the two routers. If a system stops receiving BFD
packets after a predefined time interval, a component in the bidirectional
path to the neighboring router is assumed to have failed. A path is declared
to be operational only when two-way communication has been established
between the systems. To establish BFD sessions, you must configure
one or more BFD clients on the same interface as BFD. BFD clients are
Ericsson IP Operating System applications or routing protocols, which use
BFD events to detect link failures; for example, BFD clients can be BGP,
OSPF, IS-IS, RSVP, and other applications.
For configuration information, see BFD.
• BGP
BGP, an EGP based on distance-vector algorithms, uses Transmission
Control Protocol (TCP) as its transport protocol. BGP operates between two
BGP nodes, called BGP speakers. After a TCP connection is established,
the two BGP speakers exchange dynamic routing information over the
connection. The exchange of messages is a BGP session between BGP
peers. Router supports BGP4.
The router supports BGP advertisement of the best external route, as speci
fied in IETF internet draft, draft-ietf-idr-best-external-03.txt.
When this feature is enabled, the system computes two best paths: the
overall best path and the best external path. If the best path is an internal
path (received from an internal peer), the speaker is allowed to advertise
the best external path to internal peers.
The best external path feature is supported for IPv4 unicast. It is supported
for BGP speakers in any role, except confederation AS Border Router
(ASBR). The feature is supported on route reflectors only if client-to-client
reflection is not in effect—that is, when all clients are fully meshed.
You can also configure the BGP diverse path feature on the router,
enabling a BGP speaker to announce the second best path—the diverse
path—instead of the best path. Announcing the diverse path as well as the
best path enables the client to select the better route. The diverse path
feature can also improve network convergence if the best path becomes
unreachable. If a router has an alternative path available, it can install
the path immediately, without waiting for a BGP speaker to announce the
new best path.
33
1/221 02-HRA 901 21/2 Uen D | 2014-06-23

In scenarios where the router acts as a pure BGP route reflector to reduce
routing table size and CPU load, you can filter which routes get downloaded
from BGP to RIB and FIB before being readvertised to peer BGP routers.
With this feature enabled, the route reflector does not download routes
before readvertising to peer routers, resulting in smaller routing tables in
the RIB and FIB and requiring less memory and CPU.
You can also filter route download to RIB for an entire address family or
for part of an address family by specifying a prefix list. When a BGP route
reflector receives a route advertisement from a peer and the network ID
matches the specified address family or prefix list, the network best path
is not downloaded to the RIB before the route reflector readvertises the
routes to its peers.
The router supports Multiprotocol BGP (MP-BGP), as defined in RFC 2283,
Multiprotocol Extensions for BGP-4, extends the use of BGP to non-IPv4
network-layer protocols.
For more information, see BGP.
• IS-IS
IS-IS is an IGP that makes routing decisions based on link-state information.
IS-IS is defined in ISO 10589, Intermediate System to Intermediate System
Intra-Domain Routing Exchange Protocol for Use in Conjunction with the
Protocol for Providing the Connectionless-mode Network Service (ISO
8473), ISO DP 10589, February 1990, and RFC 1195, Use of OSI IS-IS
for Routing in TCP/IP and Dual Environments. IS-IS supports IPv4. For
more information, see IS-IS.
• Routing Policies
SP 415/420 routing policies allow network administrators to enforce various
routing policy decisions on incoming, outgoing, and redistributed routes.
The tools used to configure routing policies include BGP AS path lists,
BGP community lists, IP prefix lists, and route maps with match and set
conditions. For more information, see Routing Policies.
• IP Multicast
IP multicast communication enables a source host to send IP packets
to any number of hosts anywhere within an IP network. It is one-to-any
communication: Multicast communication is not limited to sending packets
to a single destination host or to every host on the network. Instead,
multicast enables a source host to send IP packets to as many destination
hosts as necessary, but no more than that. For more information, see
IP Multicast .
The main challenge for multicast communication is developing a method
for determining which hosts can receive multicast traffic and which hosts
will not receive the traffic. Several different multicast protocols have been
developed, each with its own unique approach to addressing the multicast
34 1/221 02-HRA 901 21/2 Uen D | 2014-06-23

Features
challenge. The router supports Internet Group Management Protocol
(IGMP) for hosts using IPv4 addresses for discovering multicast listeners
in the local network. The router also supports the following protocols to
interact with and route traffic to other multicast routers on the network:
PIM Sparse Mode (PIM-SM)
PIM Source-Specific Multicast (PIM-SSM)
5.4.2 MPLS Networking
The router supports MPLS to efficiently forward packets through a network.
On the SP 415/420, MPLS operates across an interface in an MPLS-enabled
context.
In a conventional IP network, routers forward packets through the network from
one router to the next, with each router making an independent forwarding
decision by analyzing the packet header. Packet processing often causes
considerable forwarding delay. With MPLS, the complete analysis of the packet
header is performed only once when it enters an MPLS-enabled network. For
more information, see MPLS.
5.4.2.1 Label Distribution
To communicate labels and their meanings among LSRs, MPLS uses RSVP
or LDP, which enable dynamic label allocation and distribution in an MPLS
network.
• With RSVP, you can specify the ingress LSR and the egress LSR, but the
next hops are either configured or determined according to labels derived
from existing routing protocols. For more information, see MPLS.
• An LSR enabled with LDP can establish LSPs to other LSRs in the network.
LDP creates label bindings by assigning labels to connected routes and
advertising the bindings to neighbors. LDP also assigns labels to label
bindings learned from neighbors and readvertises the binding to other
neighbors. When an LSR advertises a label binding for a route, the LSR is
advertising the availability of an LSP to the destination of that route. LDP
can learn several LSPs from different neighbors for the same route. LDP
must be configured with an IGP, such as IS-IS or OSPF. LDP assigns a
label only to routes selected by the underlying IGP. For more information,
see LDP.
5.4.2.2 MPLS OAM Tools
For MPLS-enabled networks, you can use the LSP ping and traceroute
Operations, Administration, And Maintenance (OAM) tools for troubleshooting
MPLS LSPs. You can also use LSP traceroute to specify a range of addresses
and verify the LDP equal-cost multipath (ECMP) paths at the LER.
35
1/221 02-HRA 901 21/2 Uen D | 2014-06-23

5.4.3 MPLS-Based Solutions
The router supports solutions using MPLS networks in which customer
connectivity among multiple remote sites is deployed across a shared central
infrastructure and still provides the same access or security as a private
network. For example, it supports L2VPNs, Virtual Private Wire Service
(VPWS), and L3VPNs in MPLS network topologies.
• VPWS
A VPWS cross-connects the local SI between the local CE and your router
to a pseudowire that crosses the MPLS backbone network to the remote
PE router. A VPWS is based on L2VPN in which CE routers send Layer
2 traffic to PE routers over Layer 2 circuits, that are configured between
the PE and the CE routers.
The router serves as a PE router and supports these Layer 2 circuits:
Ethernet port and 802.1Q VLAN.
You can configure the L2VPN on PE routers and use it to cross-connect a
local Layer 2 circuit with a corresponding remote Layer 2 circuit through
an LSP tunnel that crosses the network backbone. For more information,
see VPWS (L2VPN).
• BGP/MPLS VPNs
Layer 3 BGP/MPLS VPNs are a collection of policies that control
connectivity among a set of sites. A customer site is connected to the
service provider network, often called a backbone, by one or more ports.
The service provider associates each port with a VPN context.
A BGP/MPLS VPN allows you to implement a wide range of policies. For
example, within a VPN, you can allow every site to have a direct route to
every other site (full mesh), or you can restrict certain pairs of sites from
having direct routes to each other (partial mesh).
Intra-AS hierarchical MPLS (H-MPLS) adopts a divide-and-conquer
strategy where the core, aggregation, and access networks are partitioned
in different MPLS/IP domains. The network segmentation among the
access, aggregation and core domains could be based on a single AS
multi-area design or a single AS multi-instance design.
Regardless of the type of segmentation, the H-MPLS transport concept
involves partitioning the core, aggregation, and access layers of the
network into isolated IGP/MPLS domains. Partitioning these network layers
into independent and isolated IGP/MPLS domains helps reduce the size of
routing and forwarding tables on individual routers in these domains, which
leads to better stability and faster convergence. For more information,
see BGP/MPLS VPN.
36 1/221 02-HRA 901 21/2 Uen D | 2014-06-23

Features
5.5 IP Protocol Support
The SP 415/420 supports the following IP service protocols.
• ARP
The ARP implementation is consistent with RFC 826, An Ethernet Address
Resolution Protocol, also called Converting Network Protocol Addresses
to 48.bit Ethernet Address for Transmission on Ethernet Hardware. In
addition, the router provides a configurable ARP entry-age timer and the
option to delete expired dynamic ARP entries automatically .
For more information, see ARP.
• NTP
The router supports versions 1, 2, and 3 of the Network Time Protocol
(NTP). On the router, NTP operates only in client mode. A remote NTP
server can synchronize the router, but the router cannot synchronize the
remote server.
Note: Before using NTP, the router must be configured with the IP
address of one or multiple NTP servers.
For more information, see NTP.
• DHCP
The DHCPv4 server dynamically leases IP address information to IPv4 host
clients. For IPv4 support, the router provides the following DHCPv4 support.
DHCPv4 relay server
The router acts as an intermediary between an external DHCPv4
server and the client. The router forwards requests from the client to
the DHCPv4 server and relays the responses from the server back
to the client.
For more information, see DHCP.
5.6 IP Services
The Ericsson IP Operating System supports IP filtering ACLs (for IPv4 traffic)
that work in collaboration with QoS to manage traffic flow.
ACLs
• IP Filtering ACLs
An IP ACL is a list of packet filtering rules. Based on the criteria specified
in the IP ACL associated with the packet, the router decides whether the
37
1/221 02-HRA 901 21/2 Uen D | 2014-06-23

packet is forwarded or dropped. IP ACLs filter packets by using deny and
permit statements. You can apply IP ACLs to interfaces and contexts to
affect packets on all circuits bound to the interface or all administrative
packets for a context.
Note: The SP 415/420 only supports IPv4 administrative ACLs.
For more information about ACLs, see ACLs.
5.7 Quality of Service
The Internet provides only best-effort service, offering no guaranteed packet
delivery. The Ericsson IP Operating System offers QoS differentiation based
on traffic type and application, and supports IPv4.
5.7.1 Configuring QoS on Circuits
You can attach policing (ingress) policies to ports, SIs, and 802.1Q PVCs
(single tag and dual tag circuits). For more information, see Circuits for QoS.
5.7.1.1 QoS Support on Service Instances
The router supports binding QoS services to SIs that are configured under
Ethernet ports.
The following QoS services are supported for service instances on SP 415/420:
• Policing and QoS policy bindings on ingress
• Overhead profile
• QoS priority on ingress
• Propagating priority marking to and from Ethernet using a dot1q profile
on ingress or egress
5.7.2 Rate Limiting and Class Limiting
The SP 415/420 classifies, marks, and rate-limits incoming packets.
• QoS Policing Policy
A QoS policing policy marks or rate-limits, or performs action on incoming
packets. You can apply policing policy to all packets on a particular circuit
For more information, see Rate-Limiting.
38 1/221 02-HRA 901 21/2 Uen D | 2014-06-23

Features
5.7.3 Queueing and Scheduling
After classification, marking, and rate limiting occurs on an incoming packet, the
packet enters an output queue for servicing by an egress traffic card scheduler.
The SP 415/420 supports up to eight queues per port. Queues are serviced
according to a queue map scheme or QoS scheduling policy, or both.
The SP 415/420 uses PWFQ policies for QoS scheduling. PWFQ policies
support the following features.
• Attachable to ports
• Eight queues
• QoS priority marking and queue maps to determine the egress queue
The policy can reference a customized queue map.
• Up to 32 congestion avoidance maps to specify Random Early Detection
(RED) parameters
• Scheduling algorithm that is both priority- and weight-based
Each queue has the fixed priority. Queue priority from queue 0 to queue 7
is from highest to lowest (Queue 0 has the highest priority, and queue 7
has the lowest priority).
The queues whose weights are 0 are scheduled in strict-priority mode,
and whose weights are not 0 are schedule in WDRR. The queues whose
weights are 0 have the high scheduling priority than other queues.
For more information about the PWFQ scheduling algorithm, see Queuing
and Scheduling.
• Port Shape
Each PWFQ policy can use a maximum rate, and burst for traffic shaping.
The maximum rate is the highest rate that allows for this port.
For more information, see Queuing and Scheduling.
5.8 IP Performance Metrics
5.8.1 TWAMP Light Reflector
The Two-Way Active Measurement Protocol (TWAMP) defines a standard
for measuring round-trip network performance between any two devices that
support the TWAMP protocols. TWAMP light is a simplified architecture of
TWAMP without TWAMP-Control protocol. In this architecture, the roles of
Control-Client, Server, and Session-Sender are implemented in one host as
39
1/221 02-HRA 901 21/2 Uen D | 2014-06-23

the controller, and the role of Session-Reflector is implemented in another host
as the responder. The reflector acts as light test points in the network. The
following figure shows the architecture of TWAM light:
Session-Sender
Session-Reflector
TWAMP-Test
Server
Controller Responder
Control-Client
G103096A
Figure 25 TWAMP Light Architecture
The SP 415/420 works as a TWAMP-Light reflector without a TWAMP-Control
protocol. It interoperates with the session-sender, and TWAMP server on
another device that supports TWAMP.
In the following figure, one device is the session-sender, and the other two
devices are Ericsson SP 415/420 that works as TWAMP reflectors.
G103087B
TWAMP Light Reflector
TWAMP Light Reflector
Controller
and Sender
Figure 26 Basic TWAMP Deployment
40 1/221 02-HRA 901 21/2 Uen D | 2014-06-23

User Interfaces
6 User Interfaces
The router provides the following interfaces to access, manage, and configure
the system, as well as access node state information.
• CLI
• SNMP (see RMON and SNMP)
6.1 Using the CLI
The CLI is the primary interface to the SP 415/420.
You can access the CLI in the following ways.
• Ethernet management port connection to a local management workstation
Requires a PC-type workstation using a Telnet or Secure Shell (SSH)
session. Requires a shielded Ethernet crossover cable for a local
workstation.
• Ethernet management port connection to a remote management
workstation
Requires a PC-type workstation using a Telnet or SSH session. Requires a
shielded Ethernet straight cable (shipped with the system) or a router or
bridge.
• Console port connection to a remote console terminal
Requires either an ASCII or VT100 console terminal or equivalent that runs
at 9600 baud, 8 data bits, no parity, 1 stop bit, or a PC-type workstation
with a terminal emulator in the same configuration as the ASCII or VT100
terminal.
Note: You must log on using the console and configure an IP address before
logging on remotely.
It is advisable to have two access methods available, such as a remote
workstation connected to the Ethernet management port and a console port
connected to a terminal server (a console cable is shipped with the system).
Several administrative tasks are performed with the CLI through a terminal
server, because some processes, such as reloading or upgrading the software,
interrupt an Ethernet management port connection.
For more information about command modes and prompts, the command
hierarchy, privilege levels for commands and administrators, see Using the CLI.
41
1/221 02-HRA 901 21/2 Uen D | 2014-06-23

7 Administration
The router has many features for managing security and performance,
monitoring and reporting on status, and troubleshooting the system.
For information on data collection when customers submit a customer service
request (CSR) to Technical Support, see Data Collection Guideline
7.1 Managing Security
The SP 415/420 provides forwarding and advanced Layer 2 to Layer 7
services to carriers around the world. With the rapid expansion of the
Internet—connected devices, bandwidth, and multimedia (data, voice, and
video)—security has become an important aspect of handling internet traffic.
An SP 415/420 router deployed at the edge of the network is directly exposed
to various types of security attacks. The comprehensive security features of
the Ericsson IP Operating System help protect the SP 415/420 router and
other nodes in the core network.
For more information, see Key Chains, TACACS+, and Restricting Access to
the CLI.
7.1.1 User Access and Operations
You can access the CLI through a directly connected console port or through
Telnet or SSH sessions to the management port. The SP 415/420 supports
login authentication (using a local user database on the SP 415/420) as well
as centralized authentication using a RADIUS or Terminal Access Controller
Access-Control System Plus (TACACS+) server.
You can manage local user accounts through the CLI. All user accounts
must have a password. Passwords are stored encrypted in the configuration
file. After you log in the first time, you can change your password using CLI
commands. By default, idle sessions are disconnected after 10 minutes. You
can configure the idle time-out interval.
You can also enhance security to eliminate risks from user operations through
the management port. A user who remotely accesses a system, for example
using a remote console can interactively change a password in a secure
manner. In addition, a super-user can grant or deny privileges to a user for
changing a password.
In the Ericsson IP Operating System, user privilege levels determine which
commands are accessible to a particular user. Users with the default privilege
level (level 6) cannot configure the system, but they can modify some ACL rule
conditions. Access to higher privilege levels is password-protected.
42 1/221 02-HRA 901 21/2 Uen D | 2014-06-23

Administration
To protect the system, you can physically and logically separate OAM traffic
from other traffic by using separate network interfaces. To provide secure
access, the Ericsson IP Operating System supports secure protocols such as
SSH, Secure Copy Protocol (SCP), and Secure File Transfer Protocol (SFTP).
SSH version 2 (SSHv2) is supported.
Unsecured access includes access through Telnet, FTP. You can disable
unsecured access to the operating system.
Event logs and alarms raised by different modules on the SP 415/420 platform
are managed by a centralized logging infrastructure. The security audit trail is
visible to the logging infrastructure, which includes successful and failed login
attempts and logouts. You can filter Logs based on the log level and directed
to multiple destinations—for example, the system console, local storage, or a
remote syslog server.
The Ericsson IP Operating System supports SNMPv1, SNMPv2, and SNMPv3.
SNMPv3 affords the greatest degree of security and is the recommended
version.
7.1.2 Layer 2 Security
The SP 415/420 platform includes various features that provide Layer 2 security
and protect against various Layer 2 attacks.
All ports on the SP 415/420 router are disabled by default. To be functional,
you must explicitly enable a port and then bind it to an interface.
By default, routing protocols are not enabled on any interfaces. VLANs are
also not configured. You must explicitly configure a VLAN by setting the port
encapsulation to 802.1Q and creating at least one PVC. If the PVC is not
explicitly configured, the VLAN is not created.
7.1.3 Layer 3 Security
The SP 415/420 platform supports various features that provide protection from
Layer 3 attacks. Malicious traffic is detected using a combination of implicit and
configured checks. The Ericsson IP OS IP stacks are, by default, hardened
against a number of threats. The forwarding plan implicitly performs Layer 3
security checks.
You can filter packets for malicious traffic by configuring IP ACLs. When you
apply an ACL to an interface, packets received and sent over the interface are
subject to the rules specified in the ACL. ACLs applied at the context level are
called administrative ACLs. Only packets sent to the kernel are subject to those
ACLs. You can configure administrative ACLs used in any context to protect
the control plane from unwanted traffic.
43
1/221 02-HRA 901 21/2 Uen D | 2014-06-23

Ericsson recommends that you use the software loopback interface for all
routing protocols. However, the CLI does not enforce this practice. By default,
routing protocols are not enabled on any interface.
Authentication is implemented for all unicast IPv4 protocols. Manually
distributed keys are used for authentication. The keys are stored encrypted in
the configuration files. You can configure prefix lists to control how messages
are routed.
7.2 Managing Performance
To manage performance, you can use load balancing, and SNMP.
7.2.1 SNMP
You can enable SNMP on the router to monitor one or more network devices
from a central location. An SNMP management system includes one or
more SNMP agents, an SNMP Manager, and the protocols to communicate
information between the SNMP agent and manager entities, such as trap
notifications. You can also configure a target for collecting SNMP data. For
more information, see RMON and SNMP.
7.3 Monitoring and Reporting Tools
7.3.1 Logging
The Ericsson IP Operating System contains two log buffers: main and debug.
Log files must be sent to Customer Support when submitting a support request.
In large installations, it is recommended to enable the logging of system events
to a remote Syslog server that is reachable by the current context.
By default, log messages for the local context are displayed in real time on the
console. Nonlocal contexts are not displayed in real time on the console. To
change this behavior and display log messages in real time, use the logging
console command in context configuration mode in the context of interest.
You can display log messages in real time from any Telnet session using the
terminal monitor command in exec mode.
The router also supports In-service Performance (ISP) logging, stored in the
flash memory of the router. It collects information about predefined system
events that can have a potential impact on applications. It enables support
representatives to perform root-cause analysis and troubleshooting. It also
logs events for third-party applications.
For more information, see Logging.
44 1/221 02-HRA 901 21/2 Uen D | 2014-06-23

Administration
7.3.2 Reporting
The SP 415/420 provides show commands to display system features and
functions. For example, you can use the monitoring commands in Table 6. For
information about specific commands, see the Command List. For information
about using show commands, see Using the CLI.
Table 6 Types of Monitoring Commands
Type of Command Commands Notes
Monitor a system
component
show chassis
show hardware
show card
Displays status of cards installed in the
chassis.
Displays detailed hardware information.
Displays detailed card information.
show circuit
counters
Displays statistics for one or more circuits.
Monitor the status
of a process and
provide continuous
updates
monitor process Monitors the current status of a specified
category of processes, and provides
continuous status updates. Enter this
command in exec mode.
Monitor files in
memory
directory
pwd
Displays a list of files in the specified
directory.
Displays the current working directory.
Enter these commands in exec mode.
Monitor a process show process Displays current status of a process. Enter
this command in any mode.
Display a software
release or version
show release Displays release and installation
information.
Enter these commands in any mode.
Monitor an
administrator
session
show privilege
show public-key
Displays the current privilege level for the
current session.
Displays the public keys for an
administrator.
Enter these commands in any mode.
Monitor the system show configuration Displays the configuration commands for a
feature. Enter this command in any mode.
show memory Displays memory statistics. Enter this
command in any mode.
show system alarm Displays system alarms at one or more
levels. Enter this command in any mode.
45
1/221 02-HRA 901 21/2 Uen D | 2014-06-23

Table 6 Types of Monitoring Commands
Type of Command Commands Notes
show port synchrono
us-mode
Displays synchronization information for
one or all synchronous mode ports.
show synchronizatio
n ptp-port
Displays information about PTP port.
show 1pps port Displays information about 1pps port.
show synchronizatio
n input-source
Displays information about the
synchronization input sources.
7.3.3 Troubleshooting
For information on resolving problems with the following guides:
• Logging
• SNMP MIB Notifications
• Troubleshooting Guide
• Emergency Recovery Guide
8 Technical Specification
This section summarizes the technical specifications for SP 415/420.
8.1 Power Supply
SP 415/420 supports the following AC/DC power connections.
• PSU DC: -38 to -60 V DC, 5 A
• PSU AC: 100 to 240 V AC, 45 to 65 Hz, 2 A
The base platform provides two hot swappable redundant PSU slots. The
following configurations are supported:
• One PSU DC or one PSU AC
• Two PSU DCs or two PSU ACs
46 1/221 02-HRA 901 21/2 Uen D | 2014-06-23

Technical Specification
Power redundancy is configured if one PSU fails in this configuration.
The power consumption for SP 415/420 is described as follows:
SP 415 • 75 W (Max.)
Fully configured with two PSUs, two eight-port E1/DS1 CES
expansion modules, fan tray and SFPs (1.3 W at maximum)
• 53 W
Configured with one PSU, one eight-port E1/DS1 CES
expansion module, eight SFPs, and fan tray
SP 420 • 100 W (Max.)
Fully configured with two PSUs, two one-port 10GE expansion
modules, fan tray, SFPs (1.3 W at maximum) and XFPs (4 W
at maximum)
• 58 W
Configured with one PSU, one eight-port E1/DS1 CES
expansion module, fan tray, ten SFPs and two XFPs
Note: The current maximum power consumption of SP 415/420 is for current
version. SP 415/420 supports higher electrical capacity (for example,
120 W for SP 415 and 150 W for SP 420) for future proof purposes.
8.2 Environmental Conditions
The equipment operates under the following constraints:
• Continuous Conditions (Full performance)
Industrial Temperature: -40 to +65
C
Commercial Temperature: 0 to +50
C
Relative Humidity: 0 to 95%
Note: For industrial temperature, the service provider needs to purchase and
uses industrial temperature SFP/XFPs. If any commercial temperature
SFP/XFP is inserted, the supported temperature range for SP 415/420
is 0 to 50
C.
8.3 Dimensions and Weight
The following dimensions and weight apply for SP 415/420:
• Weight: 8 kg
• Nominal Dimensions (D×W×H): 255×446×66.68 mm
47
1/221 02-HRA 901 21/2 Uen D | 2014-06-23

8.4 Base Platform Interface and Indicators
8.4.1 Base Platform Interface
SP 415 interfaces from base platform are specified in the following table:
Table 7 SP 415 Base Platform Interface
Interface Ports Number of
Connectors
Management Interface RJ45: 10/100/1000 Base
TX
1
Console Port RJ45 1
Sync Port RJ45 2
USB USB 2.0 1
GE Ethernet RJ45 or SFP 16
(1)
Earth Grounding Two-hole
compression-type
1
(1) 8 Combo GE plus 8 SFP GE
SP 420 interfaces from base platform are listed in the following table:
Table 8 SP 420 Base Platform Specifications
Interface Ports Number of
Connectors
Management Interface RJ45: 10/100/1000 Base
TX
1
Console Port RJ45 1
Sync Port RJ45 2
USB USB 2.0 1
GE Ethernet RJ45 and SFP 20
(1)
10 Gbit Ethernet XFP 2
Earth Grounding Two-hole compression-ty
pe
1
(1) 8 Combo GE plus 12 SFP GE
8.4.2 Indicators
The following system status indicators (LEDs) are located on the front panel
of the base platform:
48 1/221 02-HRA 901 21/2 Uen D | 2014-06-23

• Fault
• Power
• Oper
• Sync
Table 9 Indicators Front Panel
Name Color Status Instruction
On Fault
Fault Red
Off No fault
On Power on
Power Green
Off No power
On Operation (no fault)
Oper Green
Off CPU is not in normal operating state
On Box is synced to external clock source
Sync Green
Off Box is using the local clock as the
reference
Note: Every unit connected to the base platform has its own indicators.
Detailed information is provided in Hardware Troubleshooting.
8.5 Modules
8.5.1 Fan Tray
SP 415/420 supports field replaceable fan tray, which contains three fans.
The fan tray is used to cool the product. The air flow is designed from the
right side to the left side.
SP 415/420 supports two kinds of fan tray options with the same cooling
performance:
• Fan tray without an alarm port: Originally installed in SP 415/420.
• Fan tray with an alarm port: Support DB-15 connector alarm port on the
front panel for customer alarm indication of network management system
if needed. The alarm port includes six alarm input pins and two alarm
output pins.
49
1/221 02-HRA 901 21/2 Uen D | 2014-06-23

8.5.2 Air Filter
SP 415/420 supports an optional field replaceable air filter, which is composed
of fibrous materials and can remove solid particulates from the air, such as
dust, pollen, mold, and bacteria.
8.5.3 Expansion Modules
This chapter describes the following two expansion modules supported in SP
415/420:
• Eight-port E1/DS1 CES expansion module
• One-port 10 GE XFP expansion module
8.5.3.1 Eight-Port E1/DS1 CES Expansion Module
E1/T1
1 2 3 4 5 6 7 8
Fault
Power
8p E1/T1 CES
G100447A
Figure 27 Overview of the Eight-Port E1/DS1 CES Expansion Module
The features that eight-port E1/DS1 CES expansion module supports are as
follows:
• Full-Featured DS1/E1 LIU/Framer/TDM-Over-Packet
• Support 8 DS1/E1 link
• Multi-protocol Encapsulation Supports IPv4, and Metro Ethernet
• Packet Loss Compensation and Handling of Misordered Packets
Table 10 Eight-Port E1/DS1 CES Expansion Module Specifications
Specification Values
Number of ports 8
Speed E1: 2.048 Mbps, DS1: 1.544 Mbps
Protection (facility) None
Interface Electrical
Connector type RJ-45
Cable type Category 6 shielded pair
Impedance type 120
50 1/221 02-HRA 901 21/2 Uen D | 2014-06-23

There are two indicators on the expansion module panel. The indicator is used
to indicate the state of the expansion module.
Table 11 Indicators Definition
Name Color Status Meaning
Red On There is a fault on the expansion
module.
Fault
Red Off No fault
Green On Expansion module is powered up.
Power
Green Off No power
8.5.3.2 One-Port 10GE XFP Expansion Module
Link/Act
XFP 10G Ethernet
1 port 10GE LAN
Fault
Power
G100448A
Figure 28 Overview of the One-Port 10GB Expansion Module
The one-port 10GE XFP expansion module consists mainly of a high speed
10G Ethernet PHY chip, voltage management and EEPROM. Similar to the
10GE XFP ports existed on the SP 420 front panel, the 10GE port on the 10GE
module also requires XFP transceiver for connection.
This expansion module occupies a single slot in the SP 415/420. Any of the
following types of 10-Gbps XFP transceivers is supported:
• 10GE-SR
• 10GE-LR
• 10GE-ER
• 10GE-ZR
Table 12 LEDs Definition
Red On There is a fault on the expansion
module.
Fault
Red Off No fault
Green On Expansion module is powered up.
Power
Green Off No power
51
1/221 02-HRA 901 21/2 Uen D | 2014-06-23

There is an indicator for the XFP port. The indicator of the XFP is not integrated
with the connector. It is on the panel.
Table 13 Definition of the XFP LEDs
Green On Link
Green Off Not link
Link/Act
Green Blink Activity
8.6 Cables
8.6.1 External Timing Cables
An external timing cable provides a connection from an external synchronization
source. SP 415/420 provides external timing connection through the Sync
port on its front panel. The sync port is a 1PPS + TOD interface like the one
from the GPS.
Table 14 Cable Specification for External Timing Cable
Interface Description Connectors Cable Maximum
Distance
External
Timing
Category
6 shielded
Ethernet
cable
RJ-45 Female RJ-45 Male None
Table 15 Sync Port Pin Assignments
Pin Number Signal Definition Notes
1 NC N
2 NC N
3 422_1_N 1pps
4 GND RS422 GND
5 GND RS422 GND
6 422_1_P 1pps
7 422_2_N TOD
8 422_2_P TOD
The detailed cable and pin assignment for Ethernet and E1/DS1 cables are
described as in the following chapters.
52 1/221 02-HRA 901 21/2 Uen D | 2014-06-23

8.6.2 Traffic Cables
8.6.2.1 10/100/1000 Ethernet and Fast Ethernet–Gigabit Ethernet Cables
SP 415/420 supports the auto crossover function for Ethernet connection
cables. It is not necessary to choose straight or crossover cable for connecting
to the SP 415/420.
Table 16 Cable Specification for External Timing Cable
Interface Description Connectors Cable Maximum
Distance
10/100/1000
Ethernet
Category
6 shielded
Ethernet
cable
RJ-45 Female RJ-45 Male 328.1 ft -
100.0 m
The tables below show the pin assignment for Ethernet cables. Both ends of
this shielded and grounded cable are terminated in standard RJ-45 eight-pin
modular plugs.
Table 17 10/100/1000 Ethernet Straight Cable Pin Assignments
Pin Signal Definition
1 TX_D1+
2 TX_D1-
3 RX_D2+
4 BI_D3+
5 BI_D3-
6 RX_D2-
7 BI_D4+
8 BI_D4-
Table 18 10/100/1000 Ethernet Crossover Cable Pin Assignments
Pin Signal Definition Other End Pin #
1 TX_D1+ 3
2 TX_D1- 6
3 RX_D2+ 1
4 BI_D3+ 7
5 BI_D3- 8
6 RX_D2- 2
53
1/221 02-HRA 901 21/2 Uen D | 2014-06-23

Pin Signal Definition Other End Pin #
7 BI_D4+ 4
8 BI_D4- 5
Note: Both straight and crossover specified cables are accepted for SP
415/420 connection.
8.6.2.2 Transceiver-Based Cables
Transceiver-Based Gigabit Ethernet Traffic Cables are described in the table
below:
Table 19 Cable Specifications for Transceiver-Based Gigabit Ethernet
Type Description Connector Cable Maximum
Distance
BX SFP
transceiver
Single-mode
fiber 9/125
Cm
LC female LC male 6.2 mi - 10.0
km
Single-mode
fiber 9/125
Cm
LC female LC male 9.3 mi - 15 km
FE SFP
transceiver
Multimode
fiber 62.5/12
5 Cm
km
TX transceiver 4-pair,
Category
6 shielded
twisted-pair
RJ-45 RJ-45 328.1 ft -
100.0 m
Multimode
fiber 62.5/12
5 Cm
LC female LC male 1,640.4 ft -
500.0 m
SX SFP
transceiver
Multimode
fiber 50/125
Cm
LC female LC male 656.2 ft -
200.0 m
LX SFP
transceiver
Single-mode
fiber 9/125
Cm
km
ZX SFP
transceiver
Single-mode
fiber 9/125
Cm
km
SR/SW XFP
transceiver
Multimode
fiber 62.5/12
5 Cm
LC female LC male 984.4 ft -
300.0 m
54 1/221 02-HRA 901 21/2 Uen D | 2014-06-23

Type Description Connector Cable Maximum
Distance
LR/LW XFP
transceiver
Multimode
fiber 50/125
Cm
km
ER XFP
transceiver
Single-mode
fiber 9/125
Cm
km
ZR XFP
transceiver
Single-mode
fiber 9/125
Cm
km
DWDM
transceiver
Single-mode
fiber 9/125
Cm
km
Note: Commercial temperature for most SFP/XFP is 0 to +70
C, only for SFP
1000Base-T (EPN: RDH90120/49800 R4A) is 0 to +85
C.
8.6.3 E1/DS1 Cables
The E1/DS1 cable specification and signal definition are described in this
chapter.
Table 20 Transceiver-Based Gigabit Ethernet Traffic Cables
Interface Desp. Connectors Maximum Distance
Channelized
E1/DS1
4-pair, Category 6
shielded
RJ-45 328.1 ft - 100.0 m
(1)
(1) May need cable converters before connecting to SP 415/420.
The table below shows the pin assignment for E1/DS1 Cables.
Table 21 E1/DS1 Cable Pin Assignments
Pin Signal Definition
1 TX+
2 TX-
3 N/A
4 RX+
5 RX-
6 N/A
7 N/A
8 N/A
55
1/221 02-HRA 901 21/2 Uen D | 2014-06-23

8.6.4 Console Cables
The console port signal definition is described in this chapter.
Table 22 Console Port Signal Definition
Other End Pin # Signal Definition Input/Output
1 - -
2 DTR Ouput
3 TxD Ouput
4 GND -
5 GND -
6 RxD Input
7 DSR Input
8 - -
8.6.5 Alarm Port
The alarm port signal definition is described in this chapter.
Note: This chapter is valid when the fan tray with an alarm port is selected.
Table 23 Alarm Port (HD DB-15 connector) Signal Definition
1 Alarm Input 1 Input
7 Alarm Input R -
8 Alarm Output R -
9 Alarm Output 1 Output
10 Alarm Output 2 Output
11 - -
12 - -
13 - -
56 1/221 02-HRA 901 21/2 Uen D | 2014-06-23

Software Standard Declaration
14 - -
15 - -
8.7 Flash Memory
SP 415/420 supports 2 GB NAND flash.
9 Software Standard Declaration
This chapter describes the standards which SP 415/420 supports.
L2 Protocol Technologies:
• 802.1Q IEEE Standard for Local and Metropolitan Area Networks: Virtual
Bridged Local Area Networks
L3/L2.5 Protocol Technologies:
• draft-ietf-ospf-prefix-hiding-02
• Internet Draft, Advertisement of the best external route in BGP, March 2011
• Internet Draft, BGP Support For Four-Octet AS Number Space, May 2001
• RFC 826, An Ethernet Address Resolution Protocol, or Converting Network
Protocol Addresses to 48.bit Ethernet Address for Transmission on
Ethernet Hardware
• RFC 1195, Use of OSI IS-IS for Routing in TCP/IP and Dual Environments
[3] RFC 5309, Point-to-Point Operation over LAN in Link State Routing
Protocols
• RFC 1997, BGP Communities Attribute, August 1996
• RFC 2328, OSPF Version 2
• RFC 2385, Protection of BGP Sessions via the TCP MD5 Signature Option,
August 1998
• RFC 2439, BGP Route Flap Damping, November 1998
• RFC 2627, QoS Routing Mechanisms and OSPF Extensions
57
1/221 02-HRA 901 21/2 Uen D | 2014-06-23

• RFC 2796, BGP Route Reflection - An Alternative to Full Mesh IBGP, April
2000
• RFC 2842, Capabilities Advertisement with BGP-4, May 2000
• RFC 2858, Multiprotocol Extensions for BGP-4, June 2000
• RFC 2918, Route Refresh Capability for BGP-4, September 2000
• RFC 3065, Autonomous System Confederations for BGP, February 2001
• RFC 3101, The OSPF Not-So-Stubby Area (NSSA) Option
• RFC 3107, Carrying Label Information in BGP-4
• RFC 3623, Graceful OSPF Restart
• RFC 3630, Traffic Engineering Extensions to OSPF Version 2
• RFC 4271, Border Gateway Protocol 4 (BGP-4), January 2006
• RFC 4274, Graceful Restart Mechanism for BGP, January 2007
• RFC 4576, Using a Link State Advertisement (LSA) Options Bit to Prevent
Looping in BGP/MPLS IP Virtual Private Networks (VPNs)
• RFC 4577, OSPF as the Provider/Customer Edge Protocol for BGP/MPLS
IP Virtual Private Networks (VPNs)
• RFC 5291, Outbound Route Filtering Capability for BGP-4, August 2008
• RFC 5292, Address-Prefix-Based Outbound Route Filter for BGP-4, August
2008
• RFC 5305, IS-IS Extensions for Traffic Engineering
• RFC 5309, Point-to-Point Operation over LAN in Link State Routing
Protocols
• RFC 5880 Bidirectional Forwarding Detection (BFD)
• RFC 5881 Bidirectional Forwarding Detection (BFD) for IPv4
• ISO DP 10589, February 1990, Intermediate System to Intermediate
System Intra-Domain Routing Exchange Protocol for Use in Conjunction
with the Protocol for Providing the Connectionless-mode Network Service
(ISO 8473)
LAG:
• IEEE 802.1ad - Provider Bridges
• IEEE 802.1AX (2008) Link Aggregation Group (LAG)
VPWS
58 1/221 02-HRA 901 21/2 Uen D | 2014-06-23

Software Standard Declaration
• Draft-ietf-pwe3-redundancy-bit, Pseudowire Preferential Forwarding Status
Bit
• Draft-ietf-pwe3-redundancy, Pseudowire Redundancy
• RFC 3916, Requirements for Pseudo-Wire Emulation Edge-to-Edge
(PWE3)
• RFC 4026, Provider Provisioned Virtual Private Network (VPN) Terminology
• RFC 4446, IANA Allocations for Pseudowire Edge to Edge Emulation
(PWE3)
• RFC 4447, Pseudowire Setup and Maintenance using LDP
• RFC 4448, Encapsulation of Ethernet over MPLS
• RFC 4664, Framework for Layer 2 VPNs
L3VPN
• RFC 2547, BGP/MPLS IP VPNs
• RFC 4364, BGP/MPLS IP Virtual Private Networks (VPNs)
MPLS
• RFC 2702, Requirements for Traffic Engineering Over MPLS
• RFC 3031, Multiprotocol Label Switching Architecture
• RFC 3032, MPLS Label Stack Encoding
• RFC 3209, RSVP-TE: Extensions to RSVP for LSP Tunnels
• RFC 3443, Time To Live (TTL) Processing in MPLS network
• RFC 3473, RSVP-TE Extension to Support GMPLS
• RFC 3478, Graceful Restart Mechanism for LDP
• RFC 3479, Fault Tolerance for the Label Distribution Protocol (LDP)
• RFC 4090, Fast Reroute Extensions to RSVP-TE for LSP Tunnels
• RFC 4379, Detecting Multi-Protocol Label Switched (MPLS) Data Plane
Failures
• RFC 5036, LDP Specification
• RFC 5283, LDP Extension for Inter-Area Label Switched Paths (LSPs)
• RFC 5443, LDP IGP Synchronization
• RFC 5561, LDP Capabilities
59
1/221 02-HRA 901 21/2 Uen D | 2014-06-23

• RFC 5918, Label Distribution Protocol (LDP) 'Typed Wildcard' Forward
Equivalence Class (FEC)
• RFC 5919, Signaling LDP Label Advertisement Completion
QoS
• RFC 1700, Assigned Numbers
• RFC 2475, An Architecture for Differentiated Services
• RFC 2697, A Single Rate Three Color Marker
• RFC 3140, Per Hop Behavior Identification Codes
• RFC 3246, An Expedited Forwarding PHB (Per-Hop Behavior)
• RFC 3247, Supplemental Information for the New Definition of the EF PHB
(Expedited Forwarding Per-Hop Behavior)
• RFC 3260, New Terminology and Clarifications for Diffserv
• RFC 3270, MPLS Support of Differentiated Services
• RFC 4594, Configuration Guidelines for DiffServ Service Classes
Synchronization Technology:
• IEEE 1588v2, Precision Clock Synchronization Protocol
• ITU-T G.781, Synchronization Layer Functions
• ITU-T G.8261, Timing and Synchronization Aspects in Packet Networks
• ITU-T G.8262, Timing Characteristics of Synchronous Ethernet Equipment
Slave Clock
• ITU-T G.8264, Distribution of Timing Through Packet Networks
Network Management Technologies:
• Telnet
• SSHv2
• TACACS+
• SNMP V1/ V2c/ V3
• RMON
• RFC 2131, Dynamic Host Configuration Protocol
• RFC 2132, DHCP Options and BOOTP Vendor Extensions
60 1/221 02-HRA 901 21/2 Uen D | 2014-06-23

Appendix: SFP/XFP Ethernet Interfaces
• RFC 2865, Remote Authentication Dial In User Service (RADIUS)
• RFC 3004, The User Class Option for DHCP
• RFC 3046, DHCP Relay Agent Information Option
Other Technologies:
• RFC 1305, Network Time Protocol
• SFTP
10 Appendix: SFP/XFP Ethernet Interfaces
The following SFP/XFP transceivers are supported on SP 415/420:
Table 24 SFP/XFP Ethernet Interfaces - Part One
SFP/
XFP
Type Temp EPN Fiber
Type
Wavelen
gth
nm
Max Supp
orted
Distance
Power
Consum
ption
Launche
d Power
min/max
dBm
SFP 1000Bas
eSX
I RDH
102
44/11
MMF 850 550 m Max: 1.0
W
-8.5/-3.5
I
SFP 1000Bas
eLX
C
RDH
102
45/1
SMF 1310 5 km Max: 0.85
W
-9.5/-3.0
SFP 1000Bas
eZX
I RDH
102
44/41
SMF 1550 80 km Max: 1.0
W
0/5
SFP 1000Bas
e-T
C RDH
901
20/49
800
N/A N/A N/A Max: 1.0
W
N/A
SFP 1000Bas
eBX-U
I RDH
102
48/1
SMF TX: 1310
RX: 1490
10 km Max: 1.0
W. Typica
l: 0.8 W
-9/-3
SFP 1000Bas
eBX-D
I RDH
102
48/2
SMF TX: 1490
RX: 1310
10 km Max: 1.0
W. Typica
l: 0.8 W
-9/-3
61
1/221 02-HRA 901 21/2 Uen D | 2014-06-23

SFP/
XFP
Type Temp EPN Fiber
Type
Wavelen
gth
nm
Max Supp
orted
Distance
Power
Consum
ption
Launche
d Power
min/max
dBm
SFP 100Base
FX
I RDH
102
43/1
MMF 1310 400 m Max: 0.85
W
Follow
supplier
spec -20/-
14
SFP 100Base
LX10
I RDH
102
43/21
SMF 1310 15 km Max: 0.75
W
-15/-8
SFP 100Base
BX-U
I RDH
102
48/20
SMF Tx: 1550
Rx: 1310
15 km Max: 0.75
W
-13/-8
SFP 100Base
BX-D
I RDH
102
48/21
SMF Tx: 1310
Rx: 1550
15 km Max: 0.75
W
-13/-8
SFP 1000Bas
eBX20-U
I RDH
102
48/3
SMF 1310 20 km Max: 1 W
Typical:
0.8 W
-5/0
SFP 1000Bas
eBX20-D
I RDH
102
48/4
SMF 1490 20 km Max: 1 W
Typical:
0.8 W
-5/0
XFP 10GE-SR C RDH
102
39/3
MMF 850 300 m Max: 1.5
W
Follow
supplier
spec.
-5/-1
I RDH
102
102/1
SMF 1310 10 km Max: 2.5
W
-5.5/-1.0
XFP 10GE-LR
C RDH
102
39/1
SMF 1310 10 km Max: 2.5
W
Follow
supplier
spec.
-6/-1
I RDH
102
102/2
SMF 1550 40 km Max: 3.5
W
-1/2
XFP 10GE-ER
C RDH
102
39/2
SMF 1550 40 km Max: 3.5
W
Follow
supplier
spec. -4.7
/4dBm
62 1/221 02-HRA 901 21/2 Uen D | 2014-06-23

SFP/
XFP
Type Temp EPN Fiber
Type
Wavelen
gth
nm
Max Supp
orted
Distance
Power
Consum
ption
Launche
d Power
min/max
dBm
XFP 10GE-ZR C RDH
102
39/4
SMF 1550 80 Km Max: 4.5
W
Follow
supplier
spec. 0/4
SFP CWDM
GE
C RDH
901
20/81
028
SMF 1470 80 km Max: 1.0
W
N/A
SFP CWDM
GE
C RDH
901
20/81
128
SMF 1490 80 km Max: 1.0
W
N/A
SFP CWDM
GE
C RDH
901
20/81
228
SMF 1510 80 km Max: 1.0
W
N/A
SFP CWDM
GE
C RDH
901
20/81
328
SMF 1530 80 km Max: 1.0
W
N/A
SFP CWDM
GE
C RDH
901
20/81
428
SMF 1550 80 km Max: 1.0
W
N/A
SFP CWDM
GE
C RDH
901
20/81
528
SMF 1570 80 km Max: 1.0
W
N/A
SFP CWDM
GE
C RDH
901
20/81
628
SMF 1590 80 km Max: 1.0
W
N/A
SFP CWDM
GE
C RDH
901
20/81
728
SMF 1610 80 km Max: 1.0
W
N/A
SFP 1000Bas
eSX
C RDH
102
44/1
MMF 850 550 m Max: 1.0
W
-8.5/-3.5
63
1/221 02-HRA 901 21/2 Uen D | 2014-06-23

SFP/
XFP
Type Temp EPN Fiber
Type
Wavelen
gth
nm
Max Supp
orted
Distance
Power
Consum
ption
Launche
d Power
min/max
dBm
SFP 1000Bas
eZX
C RDH
102
44/4
SMF 1550 80 km Max: 1.0
W
0/5
SFP 1000Bas
eSX
I RDH
102
47/1
MMF 850 500 m Max: 1.0
W
-9.5/-4
SFP 1000Bas
eT
I RDH9
01002/
1
N/A N/A 100 m Max: 1.2
W
N/A
XFP 10GBAS
E-LBR
C RDH
102
100/1
SMF 1560.61 80 km Max: 4.5
W
-1/3
XFP 10GBAS
E-LBR
C RDH
102
100/2
SMF 1559.79 80 km Max: 4.5
W
-1/3
XFP 10GBAS
E-LBR
C RDH
102
100/3
SMF 1558.98 80 km Max: 4.5
W
-1/3
XFP 10GBAS
E-LBR
C RDH
102
100/4
SMF 1558.17 80 km Max: 4.5
W
-1/3
XFP 10GBAS
E-LBR
C RDH
102
100/5
SMF 1557.36 80 km Max: 4.5
W
-1/3
XFP 10GBAS
E-LBR
C RDH
102
100/6
SMF 1556.55 80 km Max: 4.5
W
-1/3
XFP 10GBAS
E-LBR
C RDH
102
100/7
SMF 1555.75 80 km Max: 4.5
W
-1/3
XFP 10GBAS
E-LBR
C RDH
102
100/8
SMF 1554.94 80 km Max: 4.5
W
-1/3
XFP 10GBAS
E-LBR
C RDH
102
100/9
SMF 1554.13 80 km Max: 4.5
W
-1/3
64 1/221 02-HRA 901 21/2 Uen D | 2014-06-23

SFP/
XFP
Type Temp EPN Fiber
Type
Wavelen
gth
nm
Max Supp
orted
Distance
Power
Consum
ption
Launche
d Power
min/max
dBm
XFP 10GBAS
E-LBR
C RDH
102
100/10
SMF 1553.33 80 km Max: 4.5
W
-1/3
XFP 10GBAS
E-LBR
C RDH
102
100/11
SMF 1552.52 80 km Max: 4.5
W
-1/3
XFP 10GBAS
E-LBR
C RDH
102
100/12
SMF 1551.72 80 km Max: 4.5
W
-1/3
XFP 10GBAS
E-LBR
C RDH
102
100/13
SMF 1550.92 80 km Max: 4.5
W
-1/3
XFP 10GBAS
E-LBR
C RDH
102
100/14
SMF 1550.12 80 km Max: 4.5
W
-1/3
XFP 10GBAS
E-LBR
C RDH
102
100/15
SMF 1549.32 80 km Max: 4.5
W
-1/3
XFP 10GBAS
E-LBR
C RDH
102
100/16
SMF 1548.51 80 km Max: 4.5
W
-1/3
XFP 10GBAS
E-LBR
C RDH
102
100/17
SMF 1547.72 80 km Max: 4.5
W
-1/3
XFP 10GBAS
E-LBR
C RDH
102
100/18
SMF 1546.92 80 km Max: 4.5
W
-1/3
XFP 10GBAS
E-LBR
C RDH
102
100/19
SMF 1546.12 80 km Max: 4.5
W
-1/3
XFP 10GBAS
E-LBR
C RDH
102
100/20
SMF 1545.32 80 km Max: 4.5
W
-1/3
XFP 10GBAS
E-LBR
C RDH
102
100/21
SMF 1544.53 80 km Max: 4.5
W
-1/3
65
1/221 02-HRA 901 21/2 Uen D | 2014-06-23

SFP/
XFP
Type Temp EPN Fiber
Type
Wavelen
gth
nm
Max Supp
orted
Distance
Power
Consum
ption
Launche
d Power
min/max
dBm
XFP 10GBAS
E-LBR
C RDH
102
100/22
SMF 1543.73 80 km Max: 4.5
W
-1/3
XFP 10GBAS
E-LBR
C RDH
102
100/23
SMF 1542.94 80 km Max: 4.5
W
-1/3
XFP 10GBAS
E-LBR
C RDH
102
100/24
SMF 1542.14 80 km Max: 4.5
W
-1/3
XFP 10GBAS
E-LBR
C RDH
102
100/25
SMF 1541.35 80 km Max: 4.5
W
-1/3
XFP 10GBAS
E-LBR
C RDH
102
100/26
SMF 1540.56 80 km Max: 4.5
W
-1/3
XFP 10GBAS
E-LBR
C RDH
102
100/27
SMF 1539.77 80 km Max: 4.5
W
-1/3
XFP 10GBAS
E-LBR
C RDH
102
100/28
SMF 1538.98 80 km Max: 4.5
W
-1/3
XFP 10GBAS
E-LBR
C RDH
102
100/29
SMF 1538.19 80 km Max: 4.5
W
-1/3
XFP 10GBAS
E-LBR
C RDH
102
100/30
SMF 1537.4 80 km Max: 4.5
W
-1/3
XFP 10GBAS
E-LBR
C RDH
102
100/31
SMF 1536.61 80 km Max: 4.5
W
-1/3
XFP 10GBAS
E-LBR
C RDH
102
100/32
SMF 1535.82 80 km Max: 4.5
W
-1/3
XFP 10GBAS
E-LBR
C RDH
102
100/33
SMF 1535.04 80 km Max: 4.5
W
-1/3
66 1/221 02-HRA 901 21/2 Uen D | 2014-06-23

SFP/
XFP
Type Temp EPN Fiber
Type
Wavelen
gth
nm
Max Supp
orted
Distance
Power
Consum
ption
Launche
d Power
min/max
dBm
XFP 10GBAS
E-LBR
C RDH
102
100/34
SMF 1534.25 80 km Max: 4.5
W
-1/3
XFP 10GBAS
E-LBR
C RDH
102
100/35
SMF 1533.47 80 km Max: 4.5
W
-1/3
XFP 10GBAS
E-LBR
C RDH
102
100/36
SMF 1532.68 80 km Max: 4.5
W
-1/3
XFP 10GBAS
E-LBR
C RDH
102
100/37
SMF 1531.9 80 km Max: 4.5
W
-1/3
XFP 10GBAS
E-LBR
C RDH
102
100/38
SMF 1531.12 80 km Max: 4.5
W
-1/3
XFP 10GBAS
E-LBR
C RDH
102
100/39
SMF 1530.33 80 km Max: 4.5
W
-1/3
XFP 10GBAS
E-LBR
C RDH
102
100/40
SMF 1529.55 80 km Max: 4.5
W
-1/3
SFP CWDM C RDH9
01005/
1470
RDH
102
107/1
SMF 1471 80 km 1.5 W 0/5
XFP 10GBase
-SR
C RDH9
01007/
1
RDH
102
80/1
MMF 850 300 m 1.5 W -9.5/-2.5
SFP 1000Bas
e-LX
C RDH9
0199/1
RDH
102
44/2
SMF 1310 10 km Max: 1.0
W
-9.5/-3
67
1/221 02-HRA 901 21/2 Uen D | 2014-06-23

SFP/
XFP
Type Temp EPN Fiber
Type
Wavelen
gth
nm
Max Supp
orted
Distance
Power
Consum
ption
Launche
d Power
min/max
dBm
SFP 1000Bas
e-ZX
I RDH9
01001/
1
SMF 1550 80 km Max: 1.0
W
0/5
SFP DWDM I RDH9
01006/
17
RDH
102
105/1
SMF 1563.86 80 km 1.5 W 0/4
SFP 1000BAS
E-SX
C RDH
90120
/42009
MMF 850 550 m Max: 1.0
W
-9.5/-2.5
SFP 1000BAS
E-LX
I RDH
90120/
D0210
SMF 1310 10 km Max: 1.0
W
-9.5/-3
68 1/221 02-HRA 901 21/2 Uen D | 2014-06-23

vdocuments.net_sp420-technical-description (1).pdf

vdocuments.net_sp420-technical-description (1).pdf

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to vdocuments.net_sp420-technical-description (1).pdf

Similar to vdocuments.net_sp420-technical-description (1).pdf (20)

More from gebreyesusweldegebri2

More from gebreyesusweldegebri2 (7)

Recently uploaded

Recently uploaded (20)

vdocuments.net_sp420-technical-description (1).pdf