Transportní paketová infrastruktura poskytovatelů služeb · Unified Subscriber Experience Seamless Subscriber Mobility Mobile MAG Fixed MAG LMA MPCCorporate Enterprise Fixed Residential

Transportní paketová infrastruktura poskytovatelů služeb TECH-SP3

David Jakl Cisco Systems Engineer

Cisco and/or its affiliates. All rights reserved. TECH-SP3 Cisco Public

• Static or reduced Budgets

• OTT services, video, mobility drive bandwidth, networks continue to grow

• Managing 100s to 1,000’s of devices

with different procedures, different user interfaces, different systems

Motivation: What are Service Operator Challenges?

Increasing

Operational

Complexity

Stagnant

Revenue ¥ € £ $

Explosive

Bandwidth growth

• Competitive pressure, price erosion

• Need to capture new markets but time to deploy for new services is too slow

Simple, Uniform and

Open Architecture

Scalable Architecture

Programmable, Open

Architecture


Cisco Open Network Environment

Evolved Programmable Network

Video

Business

Cloud

Mobility

NCS NCS

APIs

APIs

EDGE CORE

Access

VM VM

Edge

Core

VM

Agility

Optimize

Revenue ¥ £ € $

Always “ON”

On-Demand Services Anywhere

Dynamic Scale

Application Interaction

Seamless Experience

Policy

Real-Time Analytics

Fully Virtualized

Intelligent Convergence

Automated

Open and Programmable

Access

Evolved Services Platform

Service Broker “Business Intents” Applications and Services

CDN

VM

VM / Storage Control

Service Catalog Service Orchestration Apps


Agenda

EPN 4.0

nV Satellite

Autonomic Networking

Zero-IP

Autonomic Carrier Ethernet

Summary

EPN 4.0


Cisco’s Open Network Environment

N etwork API s (REST) a nd Services Catalog

Orchestration Mu lti-La yer Contro l, Service Chaining a nd Policy En forcement

Controllers , Collectors

onePK, OpenFlow, PCEP, N etconf/YANG, BGP-LS, GMPLS

nLigh t IP +O p tical

Virtualized Infrastructure Progra mming a nd Managing of Virtu al Resources

Physical Infrastructure Progra mming a nd Managing of Physical Resources

Network Function Virtualization Pa rt of ES P a nd EPN (Network, Stora ge, Compute )

CRS ASR 9000 ASR 9XX

NCS2000

Virtual PE Virtualized

IOS-XR VM Cisco nV

vGiLAN

VM

vFirewall

VM

vDPI

VM

vNAT

VM

vBNG

VM

vDDoS

VM

vSLB

VM

NCS4000 NCS6000

ME Series

Orchestration WAE

Quantum PS

ESP Cloud

Orchestration

Nexus

UCS

EPN System Scope

Cisco Evolved Programmable Network Leading the NFV / SDN Evolution


EPN System Overview

Unified MPLS Transport

Integrated BNG, WAG, CGN Virtualized PGW, BRAS

Virtualized RR, PCRF, CPEs

Enterprise

FMC

Corporate

Residential

FMC

IP

Consumer Convergence • Unified Subscriber Experience

Business Convergence • Unified L3 VPN experience • Seamless and Personalized BYOD

remote access and VPN Access

Virtualized Network Services

nV

MPLS

Ethernet

AN

uwav e ACM


EPN System Components


Fixed Edge Mobile Edge Converged DPI Fixed CGN

Fixed PCRF

Unified Subscriber Experience Seamless Subscriber Mobility

Mobile MAG

Fixed MAG LMA MPC

Enterprise

Fixed

Corporate

Residential

Fixed

IP

FAN

ASR 920

ME3600X

PAN

ASR-903

PAN-SE

ASR-9001

AGN-SE

PAN-SE

ASR-900X

AGN-SE

PAN-SE

ASR-900X

CN

CRS-3

NMS

Prime Network Provisioning

& Performance

AAA, PCRF

Quantum Policy Server

DHCP

Cisco PNR

FAN (PON,

DSL, Ethernet)

ME 4600, 2600

CSG : ASR

901

ASR 920

CPEs: vHN,

CSR1000v,

ISR, ASR1k

Virtualized Route Reflector

Virtualized PGW, BRAS, CPE, VXLAN GW

FAN (PON,

DSL, Ethernet)

ME 4600, 2600

OpenStack

Orchestration

NID

ME-1200


Unified MPLS: What Key Technologies Are Involved? • RFC 3107 label allocation provides hierarchy for scale

• BGP Filtering Mechanisms enable the network to learn what is needed, where is needed and when is needed

• Seamless multicast integration with LSM and mLDP

• Flexible Access Network Integration options: MPLS (Labeled BGP Extension, LDP), Ethernet, nV

• Remote LFA FRR and BGP PIC for seamless intra- and inter-domain high availability

• Contiguous and consistent Transport and Service OAM and Performance Monitoring

• Autonomic Networks for Unified MPLS Self Organization, Microwave ACM for Unified MPLS network self-correlation

• Auto-IP address assignment and dynamic change

• Virtualized L2/L3 Services Edge with PW Headend


Unified MPLS Transport – Single AS, Multi-Area LSPs between Remote Access Node Loopback

Aggregation IGP Domain

PAN-ABR

Inline-RR

CN-ABR

Inline-RR

MTG

Core IGP Domain

iBGP iBGP

iBGP IPv 4+label

Imp-Null

iBGP IPv 4+label

Next-Hop-Self Next-Hop-Self

Central RR

CN-ABR

Inline-RR

PAN-ABR

Inline-RR

iBGP


Next-Hop-Self

iBGP IPv 4+label

LDP LSP LDP LSP

pop push

swap

pop swap

swap swap pop

AN AN

Access IGP Domain Access IGP Domain

iBGP iBGP

push

push

swap push

swap

pop swap push

swap

pop swap

iBGP IPv 4+label iBGP IPv 4+label

Next-Hop-Self Next-Hop-Self

LDP LSP LDP LSP

LDP LSP iBGP Hierarchical LSP

Control

Forwarding

push

Service LSP

LDP Label

BGP Label

Service Label


Unified MPLS BGP Control Plane Single AS, Multi Area IGP, labeled BGP Access

Aggregation Node

DWDM, Fiber Rings, Mesh Topology DWDM, Fiber Rings, H&S, Hierarchical Topology Fiber or uWav e Link, Ring

Core Network Access Network Aggregation Network

Core ABR

IP/MPLS Transport

IP/MPLS Transport

Core ABR Access Nodes

IP/MPLS Transport

Example: IP RAN VPNv4 Service

Service Edge Node (BNG, MTG…)

Inline RR Inline RR

VPNv4 PE

CSG


IPv4+label PE

BNG, MSE

Inline RR

NHS

External RR

IPv4+label ABR iBGP

IPv4+label

iBGP

VPNv4

Aggregation Node

VPNv4 PE

MTG (EPC GW)

iBGP

IPv4+label

iBGP

VPNv4 iBGP

VPNv4

Inline RR

NHS

Inline RR

RR

External RR

RR

iBGP

IPv4+label IPv4+label PE

Inline RR

NHS


Optimal Routing with BGP Accumulated IGP

• Default BGP best path calculation based on IGP cost to next-hop only

– Next-hop’s IGP cost to destination ignored leading to suboptimal routing

• BGP AIGP enhances BGP best path calculation by accounting for both cost to next-hop and next-hop’s cost to reach destination

– Eliminates sub-optimal routing


PAN-ABR

Inline-RR

CN-ABR

Inline-RR

Core IGP

Domain

iBGP

iBGP IPv 4+label

CN-ABR

Inline-RR

LDP LSP LDP LSP

AN

Access IGP Domain

iBGP

iBGP IPv 4+label

LDP LSP

iBGP Hierarchical LSP

AIGP=5

Traffic Forwarding

AIGP=10

NHS

NHS

Total

Cost = 15

Total

Cost = 10


MPLS Resiliency Solution: LFA and Remote LFA

LFA simplifies management of the underling infrastructure

When no local LFA is available a node dynamically computes its remote loop free alternate node(s)

– Done during SFP calculations using PQ algorithm (see draft)

The node automatically establishes a directed LDP session to the remote node

– The directed LDP session is used to exchange labels for the FEC in question

On failure, the node uses label stacking to tunnel traffic to the Remote LFA node, which in turn forwards it to the destination

A1

C1

C2

C3

C4

A2

Backbone

Access Region

C5 Directed LDP

session


Remote LFA FRR - Protection

C2’s LIB

– C1’s label for FEC A1 = 20

– C3’s label for FEC C5 = 99

– C5’s label for FEC A1 = 21

On failure, C2 sends A1-destined traffic onto an LSP destined to C5

– Swap per-prefix label 20 with 21 that is expected by C5 for that prefix, and push label 99

When C5 receives the traffic, the top label 21 is the one that it expects for that prefix and hence it forwards it onto the destination using the shortest-path avoiding the link C1-C2.

A1

C1

C2

C3

E1

C4

A2

Backbone

Access Region

C5 Directed LDP

session

21

20

99

21 99

21 X

21 X


Ethernet Access: Hub-and-Spoke Topology

PE1

CE1 MPLS Core

PE2

MC-LAG with ICCP

PE1

CE1 MPLS Core

PE2

ICCP-SM

L2 VID Y L3 VID Z

• Active/Standby mode

• Support both L2 and L3 service

• L3 service has two configuration options: IRB

or L3 sub-interface

PE1

CE1 MPLS Core

PE2

MC-LAG with PBB-EVPN

• Active/Active per-flow or

per-service LB • Support L2 service only

with PBB-EVPN

L2 VID X L3 VID Z

• Support both L2 and L3

services (ELINE provisioned as ELAN)

• L2 service: per-VLAN load balancing

• L3 service: active/active on both links


Ethernet Access: Ring and Mesh Topology

PE1

MPLS Core

PE2 CE2

CE1

G.8032

Open Sub-ring

G.8032

PE1

MPLS Core

PE2 CE2

CE1

REP

REP and REP-AG

R-APS

RPL

Link

ALT

port

REP Edge

No

Neighbour

REP-AG

REP-AG

PE1

PE2 CE2

CE1

ICCP-SM (or STP-AG)

MPLS Core

VID X

VID Y

VID X

VID Y

VID X

VID Y

VID X

VID Y

VID X

VID Y

• Standard ring architecture

for Ethernet and xPON access

• Legacy deployed pre-

standard Cisco solution

• ICCP-SM or MST/PVST-

AG can address any L2 topology


Mobile Transport with Microwave ACM

Access Network capable to adapt intelligently to uW capacity drops:

Y.1731 VSM signals Microwave Adaptive Code Modulation changes to Access Node

MPLS Access Nodes adapt link IGP metric to new capacity triggering SPFs recalculation

Ethernet Access Nodes trigger G.8032 failover below a certain capacity threshold

Optionally Access Node can change Hierarchical QOS policy

– allows EF traffic to survive despite drop of capacity

Aggregation Node

Aggregation Node

Microwave Fading

Y.1731 VSM

Signals the

Microwave

link speed

IP/MPLS or

Ethernet

interface

Policy Logic that updates

IGP metric/G.8032 topology

and H-QOS


Multicast Architecture

Core Network

IP/MPLS Domain

Aggregation Network IP/MPLS Domain

Acces IP/MPLS domain

Core Node

Core Node

Core Node

Core Node

Aggregation Node

Aggregation Node

Aggregation Node

Recursive mLDP MP LSP

• Core/Aggregation Network runs mLDP

– Supports business mVPNs

– Supports IP multicast for eMBMS and IPTV

• Access/Pre-Aggregation Network runs PIM v4/v6 - with VRF route leaking for eMBMS – Enables eMBMS and IPTV services to reach Access Nodes (eNBs, DSLAMs)

• Sources distributed over BGP labeled unicast (v4 or v6) in Core and Aggregation and redistributed into Pre-Aggregation and Access IGP v6 processes

PIM v4/v6

Aggregation Network IP/MPLS Domain

Aggregation Node

Aggregation Node

Mcast Receiv er

Mcast Receiv er Mcast Receiv er

Mcast Source


EPN 4.0 DIGs

http://www.cisco.com/c/en/us/solutions/enterprise/design-zone-service-provider/programmable-network.html#~info-customer













EPN – MEF CE 2.0 Certified

nV Satellite


Customer

Premises

Traditional FTTx Access and Agg Network

Carrier Ethernet Aggregation

MSE

BNG

RG

FTTx Access Network

Routed/

Bridged

Ethernet Access

REP G.8032

MC-LAG

MST

Trunk/vlan N:1,

1:1

IGMP-SN

EPL,

EVPL,

ELAN,

EVLAN,

MST,

.1q tunneling

w L2PT

IGMP-SN

IGMP filter

UNI NNI

IP/MPLS

Agg

POP

Element Management Systems

(Resource Manager, Service Manager, South/Northbound Provisioning, Troubleshooting)


Customer

Premises

FTTx Access and Agg Network nV Simplicity

Carrier Ethernet Aggregation

MSE

BNG

RG

FTTx Access Network

Ethernet Access

Trunk/vlan N:1,

1:1

IGMP-SN

EPL,

EVPL,

ELAN,

EVLAN,

MST,

.1q tunneling

w L2PT

IGMP-SN

IGMP filter

Agg

POP nV Satellite

nV Satellite

nV Satellite

nV Satellite

nV Satellite

REP G.8032

MC-LAG

MST

Element Management System

(Resource Manager, Service Manager, OAM, Provisioning, Troubleshooting)

One nV Satellite System

UNI NNI

IP/MPLS

Routed/

Bridged

Element Management Systems

(Resource Manager, Service Manager, South/Northbound Provisioning, Troubleshooting)

Trunk/vlan N:1,

1:1

IGMP-SN

EPL,

EVPL,

ELAN,

EVLAN,


What is the nV Satellite Solution ?

• A single logical switch/router built by interconnecting an ASR9K and one or more smaller satellite switches

N x 10G Satellite 2

ASR 9000

N x 10G Satellite n

N x 10G

Satellite 1

…

One Virtual System


The Cisco ASR 9000v Overview nV Satellite to ASR9000 and CRS-3 host

Power Feeds

• Single AC pow er feed; or

• Redundant +24vDC, & -48vDC

Pow er Feeds

44x10/100/1000 Mbps Pluggables

• Full Line Rate Packet Processing and

Traff ic Management

• Wide range of ONS and TMG

1G SFP and 10G SFP+ optics

supported, including copper, f iber,

CWDM/DWDM

Field Replaceable Fan Tray

• Redundant Fans

• ToD/PSS Output

• BITS Out

4x10G SFP+ • Inter-Chassis Link Fabric Ports

• Plug-n-Play In-Band Management

• Automatic Discovery and Provisioning

• Co-Located or Remote Distribution

Industrial Temp Rated • -40C to +65C Operational Temperature

• -40C to +70C Storage Temperature

1 RU ANSI & ETSI Compliant

LEDs


nV Satellite – ASR 901 and ASR 903 Overview

ASR901 Satellite Platform:

Compact, Efficient & Hardened Device

– 1RU , 17.5 in x 1.72 in x 8.3 in (W*H*D)

– 12 Gbps switching capacity

– Redundant power and fans

– Low power consumption: <~50W

– Fits in 300 mm cabinets, 1RU

– Extended operating temp range -40 to 65 C

– Side-2-side cooling

Interfaces* and Per-slot Density:

– Ethernet: 12 x GE

ASR903 Satellite Platform:

Compact, Redundant, Hardened

– 3RU, 6 interface slots

– 55Gbps throughput with 1st Gen RSP

– Redundant PSUs (<550W), FANs and RSPs

– Fits in 300mm cabinet (235mm deep), 19” EIA

– Extended operating temp: -40º to 65º C (DC)

Interfaces* and per-slot density:

– Ethernet : 1x10GE and 8x1GE Interface

*Only Ethernet Interfaces are supported


nV Satellite System High-Level Overview

ASR9000 Host Satellite

Satellite access port

Satellite Auto Discovery and Control Protocol

One nV System

Fabric Links (ICLs)

• A special XR nV image on a satellite switch to make it an ASR 9000 nV satellite

• Satellite Auto Discovery and Control Protocol (SADCP) makes satellite as “virtual line card” of the ASR 9000 Host

• From end user point of view, it’s a single logical system – ASR 9000 nV System.

– All management & configuration is done on the Host chassis

• Satellite and Host can be co-located or in different locations – No distance limitation

Satell ites have zero

touch configuration

“nv” GigEthernet port


nV Auto Discovery and Control Protocol Operation


Satell ite Auto Discovery and Control Protocol

One nV System

• Discovery Phase

• A CDP-like link-level protocol that discovers satellites and maintains a periodic heartbeat

• Heartbeat sent once every second to detect satellite or fabric link failures. – CFM-based fast failure detection plan for future release.

• Control Phase

• TCP-Based control protocol used for Inter-Process Communication between Host and Satellite

• Get/Set style messages to provision the satellites and retrieve notifications from the satellite

MAC-DA MAC-SA Control VID Payload/FCS

CPU CPU


nV Satellite and Host Data Plane Forwarding


One nV System

On Satellite

• Ethernet frame received on access port

• Special nV-tag is added to frame

• Local xconnect between access and fabric port ( no MAC learning! )

• Packet is placed into fabric port egress queue and transmitted out toward Host

MAC-DA MAC-SA VLANs (OPT) Payload MAC-DA MAC-SA VLANs (OPT) Payload

MAC-DA MAC-SA nV-tag VLANs (OPT) Payload

On Host

• Host receives the packet on its satellite fabric port

• Maps frame to corresponding satellite virtual access port based on nV tag

• Packet processing is identical to local ports (L2/L3 features, QoS, ACL, etc all done in the NPU)

• Packet is forwarded out of a local port or satellite fabric port to same or different satellite


nV Satellite ID and Type Configuration

ASR9000 Host

Satellite 101

One nV System

“nV” GigEthernet port Satellite Fabric Link

(ICL*)

nv

satellite 101

description satellite 101 at bldg 16, 3700 Cisco Way

type asr9000v

serial-number CAT2039234G

secret 5 $1$S9sddjds00/3495

• Host nV configuration mode

• Define the Satellite

– Provide a unique Satellite ID

– Identify Satellite ‘Type’ (e.g. asr9000v, asr901, asr903)

– Optional: Identify the Satellite Serial Number

– Optional: specify a MD5 password for any telnet activities with Satell ite

Satellite Access Port


nV Satellite Fabric Port and Access Port Mapping Configuration

ASR9000 Host

Satellite 101

One nV System

“nV” GigEthernet port Satellite Fabric Link

(ICL*)

interface TenGigE 0/2/0/2

nv

satellite-fabric-link satellite 101

remote-ports GigabitE 0/0/0-9

• Define Satellite Fabric Port(s)

• Identify Satellite ID connected to Fabric Port

• Map Satellite Access Ports to Fabric Port Interface



nV Satellite Interface Configuration

ASR9000 Host

Satellite 101

One nV System

Interface and

Sub-interface CLI Example

interface GigabitEthernet 101/0/0/1

ipv4 address 1.1.1.1 255.255.255.0

!

interface GigabitEthernet 101/0/0/2.100 l2transport

encapsulation dot1q 100

rewrite ingress tag push dot1q 2

!

• All Satellite Configuration is done on the Host

• Satellite is a remote line card: Access ports have feature parity with ASR9K local ports

• nV Satellite interface naming follows the same local interface naming convention: sat-ID / sat-slot / sat-bay / sat-port


“nV” GigEthernet port

Satellite Fabric Link (ICL*)


nV Satellite Supported Network Topologies - Port Extender

Single Home,

Static Pinning

Single Home,

Fabric Link Bundle

Dual Home to Cluster,

Static Pinning

Dual Home to Cluster,

Fabric Link Bundle

Satellite

Satellite

Satellite

ASR9K/CRS-3

ASR9K/CRS-3

Satellite

ASR9K nV Edge

ASR9K nV Edge


nV Satellite L2 Fabric, Ring Topologies

Extending satellite connection across a Layer 2 network

• A native 802.1Q tag is added to the Satellite-Host control and data plane protocol

Expanding to support ring, & cascaded topologies

Maintains the same plug & play operational simplicity

CFM/CCM used for fast failure detection*

Satellite

VLAN-B

VLAN-A Host A

Host B CFM

CFM

Satellite

Satellite

Satellite

Host A

Host B

Satellite Satellite Host

* CFM/CCM for simple ring and cascading will be in future releases


nV Satellite L1 Dual Homing Solution

Same satellite dual homed to two separate ASR9k Hosts – Primary and Backup

Each host has independent control channel with the satellite

Satellite is notified which host is primary or backup

Satellite honors the configuration from its primary host if there is conflict. Syslog message generated if conflict

Load balancing could be per satellite, or per satellite access port (in future releases)

If satellite loses its primary host or link, failover occurs to its backup host

E-IC

CP

Satellite 1

Host A

Host B

Satellite 1: Primary Host A Backup Host B

Satellite 2

Satellite 2: Primary Host B Backup Host A


Dual-Hosts nV Satellite Configuration

Host2 Config:

redundancy iccp group 1 member neighbor 1.1.1.1 ! nv satellite system-mac 8478.ac47.dd90 ! ! nv satellite 101 type asr9000v redundancy host-priority 20 ! ! interface TenGigE0/0/2/2 nv satellite-fabric-link satellite 101 redundancy iccp-group 1 ! remote-ports GigabitEthernet 0/0/0-43

!

Host1 Config: redundancy iccp group 1 member neighbor 2.2.2.2 ! nv satellite system-mac 8478.ac47.dd90 ! ! nv satellite 101 type asr9000v redundancy host-priority 10 ! ! interface TenGigE0/0/2/2 nv satellite-fabric-link satellite 101 redundancy iccp-group 1 ! remote-ports GigabitEthernet 0/0/0-43

!

ICCP Redundancy Group

Config

Optional ICCP Group

Sys MAC Config

Host Priority Config for

Satell ite 101

Use ICCP Group 1 for

Satellite 101 Dual Hosts

Operation


Data Plane Encapsulation Ring/Cascading

On the ring, one tag is not sufficient to identify both the Satellite and Satellite access port

– 802.1ah (mac-in-mac) encapsulation for Ring

– B-MAC identifies the Satellite or Host

– I-SID identifies the Satellite access port

Switching decision at satellite:

– If MAC DA == My Satellite Chassis MAC, consume

– else continue on ring

BVID in B-MAC bridging domain

– Untagged for SDCP control packet and CFM

– Single BVID for user data packet

– Different BVID for ring local multicast replication

Host 1

Host 2

S102

S101

S103

(Satellite ID) Satellite Access Port ID

(Host ID) DMAC: Host1 SMAC: S102 BVID I-SID Original Access Port Frame


nV Satellite Simple Ring Dual Host Configuration

Host2 Config:

nv satellite 101 type asr9000v redundancy host-priority 20 ! serial-number CAT1649U12B ! satellite 103 type asr9000v redundancy host-priority 10 ! serial-number CAT1521B1BY ! ! interface TenGigE0/0/2/0 nv satellite-fabric-link network redundancy iccp-group 1 ! satellite 101 remote-ports GigabitEthernet 0/0/0-6 ! satellite 103 remote-ports GigabitEthernet 0/0/0-5 !

Host1 Config: nv satellite 101 type asr9000v redundancy host-priority 10 ! serial-number CAT1649U12B ! satellite 103 type asr9000v redundancy host-priority 20 ! serial-number CAT1521B1BY ! ! interface TenGigE0/0/2/0 nv satellite-fabric-link network redundancy iccp-group 1 ! satellite 101 remote-ports GigabitEthernet 0/0/0-6 ! satellite 103 remote-ports GigabitEthernet 0/0/0-5 !

Satellite 101 Config

Simple Ring Fabric Link,

Redundancy, and Per

Satell ite Port Mapping

Config



L2 Fabric Overview Supported Models

L2 Fabric supports satellite connectivity across Ethernet Layer 2 domains

Satellite Fabric Link Redundancy

– Single Physical Link with two VLAN/EVC

– Two Physical Links with one VLAN/EVC each

Each Host L2 sub-interface is mapped to one satellite fabric port

DMAC: H1 SMAC: S2 BVID I-SID Original Access Port Frame

S102

S101

Host 2

Host 1

Sub-interface

terminating

VLAN 10, 11

VLAN 10

Layer2 VLAN EVC Transport Network

Native L2 (802.1q) handoff

Transport VLAN (B-VLAN)

is used for packet forwarding in the L2 cloud

VLAN 11

VLAN 20

VLAN 21

VLAN 20

VLAN 21

VLAN 10

VLAN 11

Sub-interface

terminating

VLAN 20, 21


nV Satellite L2 Fabric Dual Host Configuration

Host2 Config:

nv satellite 101 type asr9000v redundancy host-priority 20 ! serial-number CAT1604B17B ! ! interface TenGigE0/0/1/0.21 encapsulation dot1q 21 nv satellite-fabric-link satellite 101 ! ethernet cfm continuity-check interval 10ms ! redundancy iccp-group 1 ! remote-ports GigabitEthernet 0/0/0-5 !

Host1 Config: nv satellite 101 type asr9000v redundancy host-priority 10 ! serial-number CAT1604B17B ! ! interface TenGigE0/0/1/0.10 encapsulation dot1q 10 nv satellite-fabric-link satellite 101 ! ethernet cfm continuity-check interval 10ms ! redundancy iccp-group 1 ! remote-ports GigabitEthernet 0/0/0-5 !


Satell ite 101 L2fabric

Dual Hosts Redundancy

and Access Port Mapping

Satell ite 101 L2fabric

VLAN Subinterface

Config

L2fabric VLAN EVC

CFM/CCM Monitoring


nV L2 Multicast offload for MEF and Enterprise services

PAN-SE

IGMP snooping

IGMP

nV ring Multicast Stream

from core locally

replicated at

satellite nodes

nV Satellite CPE

nV Satellite nV Host

nV Host

CPE

• Multicast replication offloaded from nV host to satellite

– Optimized BW utilization in nV ring

• IGMP snooping enabled on nV Hosts to learn active multicast receivers on nV ring

– Multicast membership information propagated to satellites via Cisco proprietary nV protocol

• Enables each satellite to perform multicast replication locally

• Both hosts receive same multicast membership requests from nV ring – Send single copies of same multicast streams

– Each satellite replicates multicast traffic from only one selected nV Host and forwards to receivers


nV Satellite Service Activation Testing Satellite dataplane loopback testing for PM and service activation

• User configures “nV” virtual interface just as any L2/L3 interface or sub-interface on host

• Satellite Interface loopback is configured at Host

! interface GigabitEthernet 101/0/0/1

loopback internal

!

ASR 9000 nV System


ID 101

Tester

Internal Loopback

ASR 9000 nV System


ID 101

CE

!

interface GigabitEthernet 101/0/0/1

loopback line

!

Line Loopback



Deployment and Operations: Current Methodology

Purchase

Pre-Staging

Installation (Truck Roll)

Handling Misconfigurations

(Truck Roll)

Service Activation

Management/ Customization

45


Autonomic Networking : The Vision

Self-Managing

Self-Configuring

Self-Protecting

Self-Optimizing

Self-Healing

4

6


Circling back…

Purchase Installation (Truck Roll)

Service Activation


Thus, the most efficient workflow eliminates Pre-Staging and unnecessary truck rolls:


The Autonomic Networking Infrastructure

a Network

Security

Discovery

Consistent

Reachability

• SUDI /UDI authentication

• Domain Certificates

• Autonomic Control Plane

• Channel Discovery

• Service Discovery

• Autonomic Control Plane

• Indestructible, virtual out-of- band channel

Zero-Touch Deployment

Management/Customization

(EEM / PRIME/ SDN controller)


Autonomic

Processes

Rest of Autonomic Network

The Autonomic Networking Infrastructure Explained

L2 cloud

E-LINE E-LAN

E-TREE

Channel discovery

Adjacency discovery

1

2

Goal: Find the channel (VLAN) to

communicate on Goal: Find Autonomic neighbors of the

same domain, OR download Certificate from Registrar (post-authentication)

5 Goal: Network embedded

intelligence, Service Discovery Autonomic

Processes

Autonomic

Processes

Autonomic Control Plane 4

Join AN Domain 3 Goal: Join AN Domain after

Certificate download

Autonomic Control Plane

Registrar

Goal: Secure, always available

communication channel

AAA CA

TFTP

Proxy Device New Device

TFTP

Server

Discovered


Configure a Registrar

Router#configure terminal

Router(config)#autonomic registrar

Router(config-registrar)#domain-id cisco.com

Router(config-registrar)# CA external/local

Router(config-registrar)#external-CA url <>

Router(config-registrar)#whitelist disk:whitelist.txt

Router(config-registrar)#no shut

CA

Enter Autonomic Registrar Config mode

Configure domain-id – any name will do

Specify the external CA’s url (if selected)

Specify a local whitelist (Optional)

Unshut the Registrar – You’re done!

• If external-CA url is not specified, Registrar runs an IOS CA locally

• Can the whitelist be made optional?

Choose either external or local CA


Registrar Redundancy

• A Registrar in an Autonomic domain:

• validates new devices (whitelist)

• Hands out domain certificates

• 1 Registrar failure no new devices can join the autonomic domain!

• Good practice to configure multiple registrars

• Registrars can be distributed – no need to be neighbors!

Registrar Registrar

Identical Configuration


Create a Whitelist

• Devices joining the domain must be validated before handing out certificates

• Create a whitelist (text file) of UDIs that are allowed to join

• Automatically generated by Cisco (from Bill of Sale) for new devices

• Updated by Customer for existing devices

• Load whitelist on the Registrar (manually)

Purchase Bill of Sale Customer updates for Existing devices

Registrar CSR1000v

Cisco creates whitelist for New devices


Channel Discovery

Registrar Dark Layer 2 Cloud

VLAN noted

VLAN noted

Michael


Bring up Remote Sites: Channel Discovery

Third-Party

Metro-Ethernet

Cloud

• Newly installed device is always passive

• Typically, VLAN based E-LINE services - each NID permits one VLAN

• Channel discovery helps discover the allowed VLAN

• ACP is kept separate from Data plane using QinQ service instance with fixed inner vlan = 4094

NID only allows

VLAN 416

Outer VLAN Inner VLAN

Probe for VLAN = 416 passes

through


Restricting VLAN Ranges with Channel Discovery

Registrar

• Intent configured on registrar

• Flooded through network Router#configure terminal

Router(config)#autonomic intent

Router(config-intent)#acp outer-vlans 400-420

Router(config-intent)#end


Domain Certificates Secure by Default


Validate UDI against local

whitelist

Michael


Autonomic Control Plane (ACP)


Router # show autonomic dev ice

UDI <UDI>

Dev ice ID Router-1

Domain ID cisco.com

Domain Certificate (sub:) cn=Router-1:cisco.com

Dev ice Address FD08:2EEF:C2EE::D253:5185:5472

Michael


Proxy Bootstrap


Hi Michael, I’m Steve. What do I need to configure to join ?

Nothing! Welcome to AN. I’ll be your guide.

Michael

Steve


Bring up Remote Sites: ACP

Third–Party Metro Ethernet

Cloud

CA

• Autonomic Control Plane comes up

using discovered channel

• IPv6 connectivity to Pre-Aggregation

devices (ASR903) established

FD08:2EEF:C2EE::D253:5185:547A

FD08:2EEF:C2EE::D253:5185:5237


Tree-like Control plane build-up Virtual Out Of Band Channel (VOOB)


Michael

Steve

60


Virtual Out Of Band Channel (VOOB)


Michael

Steve

AAA Misconfig /

Interface admin-shut

`


Advantages of the Autonomic Control Plane (ACP)

Completely self-managing

– No config!

Secure

– Separate (VPN) and Encrypted (IPsec)

Independent of Routing

– Only depends on link local addresses

Independent of Configuration

– Only certif icate visible in “sh running”

Visible

– Lots of show commands, debugs, etc.

Use as a “Virtual

Out-Of-Band Channel”

IPv6 link local IPv6 link local

Secure Tunnel VRF VRF

loopback loopback


Connect the outside world to the ACP

Third–Party Metro Ethernet Cloud

AAA Serv er

PnP

CA

Connect Services: DNS, AAA, PnP etc.

to ACP:

!

interface Gig0/3

autonomic connect

ipv6 address 2000::10/64

end

!


Connecting into the Autonomic Control Plane

Like normal “ip vrf forwarding” command

All devices on this interface have full access to ACP

Can SSH, SNMP, etc to loopbacks

Long term: Servers will be autonomic devices

Secure Tunnel VRF VRF

loopback loopback

Interface eth 2

autonomic connect

ipv6 address 2000::10/64


Service Discovery


Cloud Router#show autonomic service

Service IP-Addr

Syslog UNKNOWN

AAA UNKNOWN

AAA Accounting Port

AAA Authorization Port

Autonomic registrar FD08:2EEF:C2EE::D253:5185:5472

TFTP Server UNKNOWN

DNS Server UNKNOWN

• Services automatically learnt by all the devices

• Note: These are services in the Autonomic domain context, not Global

Router#show autonomic service

Service IP-Addr

Syslog 2000::1

AAA 2000::1

AAA Accounting Port 1813

AAA Authorization Port 1812

Autonomic registrar FD08:2EEF:C2EE::D253:5185:5472

TFTP Server 2000::1

DNS Server 2000::1

AAA Server

PnP

CA


Automatic Configuration Download


Cloud

• Accomplish Config download

using PnP server* or existing

TFTP servers

• Bring up Services!

TFTP


Intent Distribution

Registrar Michael

Steve

SDN Controllers

NMS Systems

• Intent = Business policy for the entire network or subset of the network

• Automatic distribution of intent using the intent distribution protocol (IDP)

• Intent Timestamp/version is hot-potatoe-forwarded in the network constantly

• If timestamp > local intent timestamp pull in intent from neighbour


Virtualizing the Registrar: CSR1000v integration

CSR1000v

AAA Serv er

PnP

CA

Network Operations Center (NOC) with CSR1000v VM

acting as the Registrar

IOIOS XE-3.15


The Autonomic Networking Infrastructure

69

a

Security

Discovery

Consistent

Reachability

Zero-Touch Deployment


(EEM / PRIME/ SDN controller)


Device Support: SP, Enterprise and IoT

Supported today:

ASR 901, ASR 901s, ASR 903, ASR 920, ME 3600, ME 3800

Catalyst 2000, 3000, 4000, NG3k, IE 2000

Open Source: Secure Network Bootstrap Infrastructure (SNBI; part of OpenDayLight Helium release)

Roadmap

ASR 9000

ASR 1000, CSR 1000, ISR-G2, ISR-4000

(more to come)


Standardisation

ANIMA Working Group: http://tools.ietf.org/w g/anima/

Early work

A Framew ork for Autonomic Netw orking http://tools.ietf.org/html/draft-behringer-autonomic-netw ork-framew ork

Making the Internet Secure by Default http://tools.ietf.org/html/draft-behr inger-default-secure

NMRG work

Autonomic Netw orking: Definitions and Design Goals http://tools.ietf.org/html/draft-irtf-nmrg-autonomic-netw ork-definit ions

Gap Analysis for Autonomic Netw orking https://tools.ietf.org/html/draft-irtf-nmrg-an-gap-analysis

Use case drafts: Those are used to derive requirements for the Autonomic Netw orking Infrastructure

Autonomic Netw orking Use Case for Netw ork Bootstrap https://tools.ietf.org/html/draft-behringer-autonomic-bootstrap

Autonomic Netw ork Stable Connectivity https://tools.ietf.org/html/draft-eckert-anima-stable-connectivity

Autonomic Prefix Management in Large-scale Netw orks https://tools.ietf.org/html/draft-jiang-anima-prefix-management

Solution drafts:

An Autonomic Control Plane https://tools.ietf.org/html/draft-behringer-anima-autonomic-control-plane

Bootstrapping Key Infrastructures http://tools.ietf.org/html/draft-pritikin-anima-bootstrapping-keyinfrastructures

Bootstrapping Trust on a Homenet (this is in homenet, not ANIMA) https://tools.ietf.org/html/draft-behr inger-homenet-trust-bootstrap

A Generic Discovery and Neg. Protocol for Autonomic Netw orking https://tools.ietf.org/html/draft-carpenter-anima-gdn-protocol

http://tools.ietf.org/wg/anima/

http://tools.ietf.org/html/draft-behringer-autonomic-network-framework









http://tools.ietf.org/html/draft-behringer-default-secure







http://tools.ietf.org/html/draft-irtf-nmrg-autonomic-network-definitions











https://tools.ietf.org/html/draft-irtf-nmrg-an-gap-analysis











https://tools.ietf.org/html/draft-behringer-autonomic-bootstrap







https://tools.ietf.org/html/draft-eckert-anima-stable-connectivity









https://tools.ietf.org/html/draft-jiang-anima-prefix-management









https://tools.ietf.org/html/draft-behringer-anima-autonomic-control-plane











http://tools.ietf.org/html/draft-pritikin-anima-bootstrapping-keyinfrastructures









https://tools.ietf.org/html/draft-behringer-homenet-trust-bootstrap









https://tools.ietf.org/html/draft-carpenter-anima-gdn-protocol










References

www.cisco.com/go/autonomic/

IEFT Drafts: See earlier slide

OpenDayLight Project SNBI: https://wiki.opendaylight.org/view/SecureNetworkBootstrapping:Main

Autonomic Networking Configuration Guide, Cisco IOS Release 15S www.cisco.com/en/US/partner/docs/ios-xml/ios/auto_net/configuration/15-s/an-auto-net-15-s-book.html

Cisco IOS Autonomic Networking Command Reference www.cisco.com/en/US/partner/docs/ios-xml/ios/auto_net/command/an-cr-book.html

[email protected]

http://www.cisco.com/go/autonomic/

https://wiki.opendaylight.org/view/SecureNetworkBootstrapping:Main

http://www.cisco.com/en/US/partner/docs/ios-xml/ios/auto_net/configuration/15-s/an-auto-net-15-s-book.html















http://www.cisco.com/en/US/partner/docs/ios-xml/ios/auto_net/command/an-cr-book.html







Auto-IP


Auto-IP

Self assigning IP address

Neighboring nodes and inserted node

negotiate physical link addresses 2

Assign unique IP address to node

being inserted 1

Connectivity established to the new

node without manual intervention to existing nodes

3

Easy node insertion and IP address assignment in L3 rings

LLDP based Auto-IP

negotiation


Auto-IP Solution Overview

For ring topology point-to-point links use /31 mask

Both interfaces are equal before the insertion

After the insertion, the “owner” and ‘non-owner” interfaces will be determined automatically depends on the adjacent Routers during the initial negotiation

After the initial IP auto negotiation and IP address assignment, the “owner” interface will keep its IP address during any ring operation: insertion/removal/movement (stickiness)

The “non-owner” interface could change its IP address based on its new neighbor accordingly during the ring operation

owner

R1

R2

R3

non-owner

non-owner

owner

Auto-IP negotiation


Auto-IP: Plug-n-Play for L3 MPLS Ring

R1 R3

Owner, P=2 non-owner, P=0

R1

R2

R3

owner

non-owner, P=0

non-owner

Owner, P=2

P=2, curr-IP=1.1.1.1

Insert

new node P=0

P=1, auto-IP=1.1.1.3

R1

R2

R3 owner non-owner

On R2:

interface GigabitEthernet0/3

mpls ip

auto-ip-ring 1 ipv4-address 1.1.1.3


mpls ip


1.1.1.1/31 1.1.1.0/31

1.1.1.2/31

1.1.1.3/31 1.1.1.0/31

1.1.1.1/31

LLDP

negotiation Initial

state

On R2:


mpls ip

ip address 1.1.1.3 255.255.255.254



mpls ip

ip address 1.1.1.0 255.255.255.254


EPN Evolution Autonomic Carrier Ethernet


Introducing Autonomic Carrier Ethernet Networks

Fully Distributed CP Fully Centralized CP Balance

IP

IGP

MPLS LDP

RSVP-TE

BGP RFC 3107

T-LDP

BGP

Autonomic IGP + SR

BGP/SDN

OpenFlow

SDN Controller

Aggregation Access

SDN Controller

APIs

Autonomic Networking + Segment Routing + SDN Minimal but “sufficient” distributed control plane intelligence

with centralized intelligence on the SDN controller.


Autonomic Carrier Ethernet Architecture Components

Autonomic Network: secure infrastructure, auto discovery, plug-n-play

Segment routing: self-deployed and self-protected, dynamic, flexible traffic engineering

SDN controller: service label provisioning, cloud integration

1 3

4 2

CE

Anycast SR label: 5001

Service label SR labels: optional

DC

Core

SDN Controller Access node

Gateway/service node


Autonomic CE1

[service label, SR label]

Cloud Edge

1 3 4 2

1 3 4 2

Auto-CE3

Auto-CE2 NID

[service label, SR label]


Segment Routing: IGP only, no need for LDP; IGP shortest path as baseline

Any node to any node transport connectivity: SR node label

Service node redundancy: anycast SR label

Link or node protection with Topology Independent Fast ReRoute (TI-FRR):

50ms FRR in any topology

Transport Architecture Overview

IGP/SR Domain: single area or process

1 4

5

6

7

DC

Core

Service Nodes Anycast label

1001

2

3

101

102

No IGP and LDP

interaction, NO hierarchy BGP and LDP LSP

50msec auto TI-FRR


Inter-domain Transport Architecture BGP free option: SDN controlled – Without Redistribution

SR label stack: {local GW, remote GW, remote node} isolated IGP islands, no redistribution required, simple, scalable

External SDN controller is used to provision the SR label stack

SDN controller can learn the SR label stack via BGP-LS or via a simple pre-provisioned

BGP Free option: no need for Hierarchical transport LSP’s – RFC 3107

1 3

4 2

CE


DC

Core

SDN Controller


CE1 Cloud edge

1 3 4 2

1 3 4 2

CE2

CE3 CPE

vCPE Anycast SR label: 2001

A

B

CE SDN Controller

GW1 GW2

SR label stack

AB: {GW1, GW2, B} = {1001,2001,2}

SR Node label: 1

SR Node label: 2

IGP island IGP island

SDN controlled cross-domain

SR label stack: [local GW, remote GW, remote node]


Inter-domain Transport Architecture BGP free option: SDN controlled – With Redistribution

SR label stack: {remote GW, remote node}: isolated IGP islands, simple, scalable, optimized label stack

All Service Nodes labels need to be visible by the Access Nodes: Redistribution is required

External SDN controller is used to provision the SR label stack

BGP Free option: no need for Hierarchical transport LSP’s – RFC 3107

1 3

4 2

CE


DC

Core

SDN Controller


CE1 Cloud edge

1 3 4 2

CE2

CPE vCPE


A

B

CE SDN Controller

GW1 GW2

SR label stack

AB: {GW2, B} = {2001,2}

SR Node label: 1

SR Node label: 2

IGP island IGP island

SDN controlled cross-domain

SR label stack: [remote GW, remote node]

All Service Nodes anycast prefixes and SID’s are

redistributed within each

CE region


Cross-Domain: CE Transport to DC Network

1

4

5

6

7

101

102

DC: SR domain

Core

Service Nodes Anycast label 1001

2

3

GW1

NID vPE: {1001, 2001, 100} vPE NID: {2001, 1001, 100}

CPE NID

NID label: 100

vPE

GW:DC

Label: 100

Service Nodes Anycast label 2001

Data Center domain can be easily integrated with Carrier Ethernet Transport network

Both the CPE/NID and the virtual PE are provisioned with SR label stack

Carrier Ethernet and Data Center network perform MPLS label forwarding between NID and vPE


Intra-domain Service Architecture

1 3

4 2

101

102

CE

DC

Core

SDN Controller

CE POP site /Cloud Edge

(distributed DC)

Anycast label 1001

Service label 60001 60002

Service label 60001, 60002

[SR label, Service label]

[{2}, 60001]

[{1}, 60001]

[{1001}, 60002]

[{1}, 60002]

P2P static Pseudowire provisioned by SDN controller or NMS

Anycast SR label used to provide Service node redundancy

TI-LFA leveraged to achieve 50ms FRR in any topology

Service 1: E-line between two nodes

Service 2: L3VPN with PWHE

From UNI on Node 1 to L3 VPN on redundant Service Node

E-Line between Node1 and Node 2

SR Node label: 1 SR Node

label: 2

Summary


Summary

EPN 4.0

nV Satellite


Zero-IP

Autonomic Carrier Ethernet

Documents

Transportní paketová infrastruktura poskytovatelů služeb · Unified Subscriber Experience Seamless Subscriber Mobility Mobile MAG Fixed MAG LMA MPCCorporate Enterprise Fixed Residential