New Technologies in Routing (and Switching) - cisco.com · Presentation_ID © 2010 Cisco and/or its affiliates. All rights reserved. Cisco Confidential 3 “The mission of the IETF

Cisco Confidential 1© 2010 Cisco and/or its affiliates. All rights reserved.

New Technologies in Routing (and Switching)Josef UngermanCisco, CCIE #6167

© 2010 Cisco and/or its affiliates. All rights reserved. Cisco Confidential 2

• Technical Activities UpdateIETF Summary

• Fast ConvergenceIP Fast Reroute (FRR)BGP Protocol Independent Convergence (PIC)BGP Add-Paths

• New ProtocolsLISPTRILLMPLS-TP

© 2010 Cisco and/or its affiliates. All rights reserved. Cisco ConfidentialPresentation_ID 3

“The mission of the IETF is make the Internet work better by producing high quality, relevant technical documents that influence the way people design, use, and manage the Internet.”

H. Alvestrand RFC 3935 A Mission Statement for the IETF October 2004 http://www.ietf.org/rfc/rfc3935.txt

IP Networks

their network.


The IETF is organized into 8 areas:General (chaired by the IETF Chair)ApplicationsInternetOperations and ManagementReal-time Applications and InfrastructureRoutingSecurityTransport

...for a total of more than 125 working groups!!


• Most of the Routing Protocol related work is done in the Routing Area, which includes these relevant working groups:bfd Bidirectional Forwarding Detectionidr Inter-Domain Routingisis IS-IS for IP Internetskarp Keying and Authentication for Routing Protocolsospf Open Shortest Path First IGP rtgwg Routing Area Working Groupsidr Secure Inter-Domain Routing

• Other relevant work does occur in other areas, some examples are:alto Application-Layer Traffic Optimization (Applications Area)lisp Locator/ID Separation Protocol (Internet Area)trill Transparent Interconnection of Lots of Links (Internet Area)grow Global Routing Operations (Operations and Management Area)


• In general, routing protocols are mature.Networks serve mission critical roles.

• Convergence, Availability and ScalabilityEnhancements to routing protocols are now incremental and look to enhance Convergence, Availability and Scalability.BFD, IP FRR, Loop Free Convergence, BGP PICBGP Optional Attribute Error Handling and Advisory Message, BGP Bestpath Selection Criteria, BGP Graceful ShutdownBGP ADD_PATH, Virtual Aggregation, EIGRP DMVPN ScalabilityLISP – Internet routing hierarchy, scalability, geo independence

• SecurityThe network infrastructure’s security is being enhanced.SIDR Origin ValidationOSPFv2, IS-IS and EIGRP AuthenticationKeying and Authentication for Routing Protocols (KARP) WG


• Reuse of Routing TechnologyReliable delivery of information to any node in the network, and the ability to calculate loop free paths is now being applied to solve non-traditional problems.Layer 2 RoutingIS-IS L2 Extensions, TRILL, OTV

Service Discovery and DistributionBGP flow-spec, bmp, OSPF Transport Instance, Advertising Generic Information in IS-IS, Proximity and Service Advertisement Framework

• Evolution of MPLS technologiesMPLS-TP (Transport Profile)MPLS-TP OAM (inc. BFD for LSP)


LFA (Loop-Free Alternate) Fast Rerouteaka. IPFRR (IP Fast Reroute)


Edge POP(Intra-POP)

Core(Inter-POP)

Classical convergence Few min. Few 10 sec.

Fast Convergence<1s

“MPLS-VPN BGP local convergence” ISIS / OSPF Fast Convergence

Fast ReRoute (Prefix Independent)<100ms

BGPPIC Edge

LFA FRR(connection-less)

MPLS TE FRR(connection oriented)


• LSP/LSA generation is optimized• Flooding & passing is optimized• Support of incremental SPT and optimized for full SPT. • Prefix Prioritization

Priority 1: IPTV sourcesPriority 2: High BGP next hopPriority 3: Other BGP next hopPriority 4: No customer traffic


• A natural extension to ISIS or OSPF FC behaviorBoosts ISIS convergence- <25msec - Prefix Independence- No new protocol extension- Per-hop behavior (no network-wide requirement)

If the topology does not allow to compute IPFRR LFA-ISIS / OSPF FC behavior

• ISIS or OSPF per-Link or per prefix LFA FRR is are simple command


S F

R1

D

Primary PathBackup Path

Route D (L:55)P NH: F, L: 33B NH: R1, L: 66

R2

20

Route D (L:33)NH: F, L: 22

Route D (L:66)NH: F, L: 22

Route D (L:22)NH: D, L: pop


S F

R1

D

Route DP NH: F, L22B NH: no LFA

Route DNH: S

R2

20

Route DNH: R3

R3

20

1010

10

BRKIPM-3000 (Advanced LFA - a simple protection technique for IP/MPLS networks )


• IGP FC: a fast IGP is one of the main building block for any FC deployments.

• LFA FRR: is a intra POP natural extension for IGP FC. • MPLS TE FRR: is a inter POP natural extension for IGP FC.

PoP

PoP

PoP

PoP

PE

P

P

PoP


BGP PICPrefix Independent Convergence


VPN 1site Bx.x.x.x/y

RD 1:1RD 2:1

RD 3:1

RR1 RR2

RR4RR3

PE1PE2

PE3

CE2CE1VPN 1site A

1. link PE2-CE2 failsIf BGP PIC Edge implemented, then traffic

goes PE1,PE2,PE3,CE2

BGP PIC Edge



RD 1:1RD 2:1

RD 3:1

RR1 RR2

RR4RR3

PE1PE2

PE3

CE2CE1VPN 1site A

6. PE1 deletes path via PE2, now going via PE3

5. RR1 and RR3 propagate withdraws

3. PE2 withdraws paths4. RR2 and RR4 propagate

withdraws

1. link PE2-CE2 failsIf BGP PIC Edge implemented, then traffic

goes PE1,PE2,PE3,CE2

2. Fast External Fallover scans BGP table, calculating new bestpaths



RD 1:1RD 2:1

RD 3:1

RR1 RR2

RR4RR3

PE1PE2

PE3

CE2CE1VPN 1site A

3. PE1 withdraws pathsIf BGP PIC Edge implemented, then

traffic goes PE1,PE3,CE2

1. link PE2 fails2. The IGP does propagate the BGP NH failure


1

10

100

1000

10000

100000

10000000

5000

0

1000

00

1500

00

2000

00

2500

00

3000

00

3500

00

4000

00

4500

00

5000

00

Prefix

msec

250k PIC250k no PIC500k PIC500k no PIC


• Initially BGP has been build to signal the best path only.• For Fast Convergence, BGP need to signal multipath and primary/backup path.

• L3VPN- Use unique RD: Unique VPNv4 addresses.-If using BGP policy (MED, ...) then BGP Best External option allow to signalling the best eBGP learn path (without withdrawing it received best internal path).- In some cases ADD-PATH option will be required


Aggregators (RRs, [confed] border routers) should advertise backup paths

backup-path-RR

PE3

RR1

Z/pPE1

PE2Z/p � PE2

Z/p � PE1

Z/p � PE1Z/p � PE2

backup-path-edge

PE3

RR1

PE1 Z/pPR1

PR2No next-hop-self

PE2Z/p � PR1Z/p � PR2

Additional-path


• The following CLI will be used to configure add-path for a global address-family

• A per-neighbor CLI will be available to turn off the add-path capability

• interim solution is best-external

router bgp <as-num>address-family <afi> <safi>additional-paths {[receive] [route-policy <policy>]}!neighbor 10.0.101.1capability additional-paths {receive | advertise} [disable]!!

Value Description Reference0 Reserved RFC 54921 Multiprotocol Extensions RFC 28582 Route Refresh RFC 29183 Outbound Route Filtering RFC 52914 Multiple Routes to Destination RFC 31075 Extended Next Hop Encoding RFC 554964 Graceful Restart RFC 472465 4-octet AS number RFC 489369 ADD-PATH draft-ietf-idr-add-paths

BGP OPEN message – CAPABILITIES


Why SIDR?• eg. YouTube prefix hijack case• IPv4 Exhaustion – prefix trading security

Current SIDR Work• Origin authentication only• The RIRs maintain a database of all known address assignments

Route Origination Authorizations, or ROAsX.509 certificates containing the assigned AS and a prefix block

• Each edge (eBGP) router in the network connects to a local server (database distributed through rsync)• Through this, the router determines if each advertisement is valid or not

RIR

X.509 ROA

rsync

Srvr-R

trProtoc

olSr

vr-R

trPr

otoc

olSr

vr-R

trPr

otoc

olSr

vr-R

trPr

otoc

ol


LISPLocation/ID Separation Protocol


Before LISP - all this state in red circle

After LISP -this amount in red circle

A 16-bit value!10^7 routes 10^4 routes


1. Improve Enterprise multi-homing– Can control egress with IGP routing– Hard to control ingress without more

specific route injection– Desire to be low OpEx multi-homed

(avoid complex protocols, no NAT)2. Improve ISP multi-homing

– Same problem for providers, can control egress but not ingress, more specific routing only tool to circumvent BGP path selection

Provider A10.0.0.0/8

Provider B11.0.0.0/8

S

R1 R2BGP


Identification (EID) used inside of sites

Locator (RLOC) used in the core



S

R1 R2

3. Decouple site addressing from provider– Avoid renumbering when site

changes providers– Site host and router addressing

decoupled from core topology4. Add new addressing

domains– From possibly separate

allocation entities5. Do 1 thru 4 and reduce the

size of the core routing tables


Locator ID

Locator

.10.0.0.1

ID

2001:0102:0304:0506:1111:2222:3333:4444IPv6:ID & Location

209.131.36.158IPv4:

ID & LocationFixed ID + Changed Locator= graceful host mobility

Changing the Semantics of the IP Address• Create a new Level of IndirectionKeep ID and Location independent


Address Components:• EIDs or IDs = new namespace (not globally routed)

End-site addrs for hosts and routers at the site (they go in DNS records)• RLOCs or Locators = existing namespace (globally routed)

Infrastructure addrs for LISP routers and ISP routers (invisible to hosts)

Site Devices (features of CE routers):• ITR – Ingress Tunnel Router

Receives packets from site-facing interfaces and encaps to remote LISP site or natively forwards to non-LISP site

• ETR – Egress Tunnel RouterReceives packets from core-facing interfaces and decaps to deliver to local EIDs at the site

© 2009 Cisco Systems, Inc. All rights reserved. Cisco Confidential 30

draft-ietf-lisp-04.txt0 1 2 30 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

/ |Version| IHL |Type of Service| Total Length |/ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+/ | Identification |Flags| Fragment Offset |/ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

OH | Time to Live | Protocol = 17 | Header Checksum |\ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\ | Source Routing Locator |\ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\ | Destination Routing Locator |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

/ | Source Port | Dest Port (4341) | UDP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

\ | UDP length UDP Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

/ |N|L|E| rflags | Nonce |LISP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

\ | Locator Status Bits | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

/ |Version| IHL |Type of Service| Total Length |/ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+/ | Identification |Flags| Fragment Offset |/ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

IH | Time to Live | Protocol | Header Checksum |\ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\ | Source EID |\ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\ | Destination EID |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


Unicast Packet Forwarding Example



SITR

DITR

ETR

ETR

Provider Y13.0.0.0/8

Provider X12.0.0.0/8S1

S2

D1

D2

PI EID-prefix 1.0.0.0/8 PI EID-prefix 2.0.0.0/8

DNS entry:D.abc.com A 2.0.0.2 EID-prefix: 2.0.0.0/8

Locator-set: 12.0.0.2, priority: 1, weight: 50 (D1)13.0.0.2, priority: 1, weight: 50 (D2)

MappingEntry

1.0.0.1 -> 2.0.0.2

1.0.0.1 -> 2.0.0.211.0.0.1 -> 12.0.0.2

Legend:EIDs -> GreenLocators -> Red

1.0.0.1 -> 2.0.0.211.0.0.1 -> 12.0.0.2

1.0.0.1 -> 2.0.0.2

12 .0 .0 .2

1 3 . 0 . 0 . 2

1 0 . 0 . 0 . 1

1 1 . 0 . 0 . 1

Policy controlledby destination site


• Control plane “data-triggered” mapping serviceMap-Request messages

– sent from an ITR to Map-Resolver when it needs a mapping for an EID, wants to test an RLOC for reachability, or wants to refresh a mapping before TTL expiration

– Map-Resolver just decapsulates the request and forwards to ALT – the correct Map-Server gets the request from ALT, encapsulates and sends to the registered ETR

• Control plane EID Registration Map-Register messages

– sent by an ETR to a Map-Server to register its associated EID prefixes, and to specify the RLOC(s) to be used by the Map-Server when forwarding Map-Requests to the ETR

Map-Reply messages– sent from an ETR directly to ITR in response to a valid map-request to provide the EID/RLOC mapping and site ingress Policy for the requested EID


LISP Control Plane

ETR12.0.0.1

ITR11.0.0.1

Legend:EIDs -> GreenLocators -> RedBGP-over-GREPhysical link

S

D


Provider X12.0.0.0/8

PI EID-prefix 1.0.0.0/8

EID Topology



LISP Control Plane

ETR12.0.0.1

ITR11.0.0.1

S

D




Map-Resolver

LISP-ALT LISP-ALT

LISP-ALT LISP-ALT

65.1.1.1

66.2.2.2Map-Server

Map-Resolver, Map-Server and ALT Infrastructure



ALT = Alternate Topologycontrol-plane only (no data)ALT Advertise EID-prefixes in BGP on an alternate topology of GRE tunnelsALT-only router for aggregating other ALT peering connections(can be any router or server)


LISP Control Plane

ETR12.0.0.1

ITR11.0.0.1

S

D




Map-Resolver

LISP-ALT LISP-ALT

LISP-ALT LISP-ALT

65.1.1.1

66.2.2.2Map-Server

(1)12.0.0.1 -> 66.2.2.2LISP Map-Register

(in AH)

(2)2.0.0.0/8

(3)2.0.0.0/8

[1] Map-Server Registration



(4)2.0.0.0/8


LISP Control Plane

ETR12.0.0.1

ITR11.0.0.1

S

D





Map-Resolver

LISP-ALT LISP-ALT

LISP-ALT LISP-ALT

65.1.1.1

66.2.2.2Map-Server

[2] Data request Triggers Map-Request

1.0.0.1 -> 2.0.0.1How do I get to 2.0.0.1?

11.0.0.1 -> 2.0.0.1Map-RequestUDP 4342

11.0.0.1 -> 65.1.1.1LISP PacketUDP 4341

(1)?


(3)?(2)?

(4)?11.0.0.1 -> 2.0.0.1Map-RequestUDP 4342

11.0.0.1 -> 2.0.0.1Map-RequestUDP 4342

66.2.2.2 -> 12.0.0.1LISP PacketUDP 4341

(5)?


LISP Control Plane

ETR12.0.0.1

ITR11.0.0.1

S

D





Map-Resolver

LISP-ALT LISP-ALT

LISP-ALT LISP-ALT

65.1.1.1

66.2.2.2Map-Server

[3] Map-Request Evokes Map-Reply

1.0.0.1 -> 2.0.0.1How do I get to 2.0.0.1?

11.0.0.1 -> 2.0.0.1Map-RequestUDP 4342

11.0.0.1 -> 65.1.1.1LISP PacketUDP 4341

(1)?


(3)?(2)?

(4)?11.0.0.1 -> 2.0.0.1Map-RequestUDP 4342

11.0.0.1 -> 2.0.0.1Map-RequestUDP 4342

66.2.2.2 -> 12.0.0.1LISP PacketUDP 4341

(5)?

(6)12.0.0.1 -> 11.0.0.1Map-ReplyUDP 4342


LISP Control Plane

ETR12.0.0.1

ITR11.0.0.1

S

D





Map-Resolver

LISP-ALT LISP-ALT

LISP-ALT LISP-ALT

65.1.1.1

66.2.2.2Map-Server

1.0.0.1 -> 2.0.0.1How do I get to 2.0.0.1?

11.0.0.1 -> 2.0.0.1Map-RequestUDP 4342

11.0.0.1 -> 65.1.1.1LISP PacketUDP 4341

(1)?


(3)?(2)?

(4)?11.0.0.1 -> 2.0.0.1Map-RequestUDP 4342

11.0.0.1 -> 2.0.0.1Map-RequestUDP 4342

66.2.2.2 -> 12.0.0.1LISP PacketUDP 4341

(5)?

(6)12.0.0.1 -> 11.0.0.1Map-ReplyUDP 4342

[4] Map-Cache Populated, data packets can flow

PolicyControlled bydestinationsite

EID-prefix: 2.0.0.0/8Locator-set: 12.0.0.2, priority: 1, weight: 100 (D1)

Map-Cache Entry


• Two important Interworking cases must be supportedLISP site to non-LISP sitenon-LISP site to LISP site

• LISP Interworking allows LISP to be deployed incrementallyLISP NATPTR – Proxy ITR/ETR

• PTRs allow LISP sites to see the benefits of ingress TE “day-one”


Interworking Using PTRs

R-prefix 65.1.0.0/16

R-prefix 65.2.0.0/16

R-prefix 65.3.0.0/16

65.0.0.0/1266.0.0.0/12

Infrastructure SolutionLegend:LISP Sites -> Green (and EIDs)non-LISP Sites -> Red (and RLOCs)

xTR

NR-prefix 1.2.0.0/16



6 6 . 1 . 1. 1

66. 2. 2. 2

6 6 . 3 . 3 . 3

6 5 .9 .2 .1

PTRBGP Advertise:

1.0.0.0/8

PTRBGP Advertise:

1.0.0.0/8PTR

BGP Advertise:1.0.0.0/8

6 5 .9 .3 .1

6 5 .9 .1.1

65.1.1.1 -> 1.1.1.1(1)

1.1.1.1 -> 65.1.1.1

Fo rw a rd N a t i ve l y

(3)

En ca ps u l a te

65.1.1.1 -> 1.1.1.165.9.1.1 -> 66.1.1.1

(2)


• Cisco-operated– >3 years operational– >60 sites, 10 countries

• Built for LISPdemonstration,experimentation, andproof-of-concept testing– IPv4 and IPv6– PITR/PETR

• Notable sites:– http://www.lisp4.facebook.com, m.lisp6.facebook.com (Facebook)– http://www.lisp4.net, http://www.lisp6.net (Univ of Oregon)– http://lisp4.cisco.com, http://lisp6.cisco.com (Cisco)


TRILL

Transparent Interconnection of Lots of Links


• Branches of trees never interconnect (no loop!!!)

� Spanning Tree Protocol (STP) uses the same approach to build loop-free L2 logical topology

� Over-subscription ratio exacerbated by STP algorithm

11 Physical Links(or Link Bundles)

5 Logical Links(or Link Bundles)


• Assigned switch addresses to all TRILL/FabricPath enabled switches automatically (no user configuration required)

• Compute shortest, pair-wise paths• Support equal-cost paths between any TRILL/FabricPath switch pairs

Plug-N-Play L2 IS-IS is used to manage forwarding topology

L1L2

S1 S2 S3 S4

S11 S12 S42L2 FabricL2 FabricL3

L4

FabricPathRouting Table

FabricPathRouting Table

Switch IFS1 L1S2 L2S3 L3S4 L4

S12 L1, L2, L3, L4… …

S42 L1, L2, L3, L4


STP DomainSTP DomainSTP DomainTRILL/FabricPathTRILL/FabricPathTRILL/FabricPath

STP Domain 1STP Domain 1STP Domain 1 STP Domain 2STP Domain 2STP Domain 2

• TRILL/FabricPath header is imposed by the ingress switch• Addresses assigned to ingress and egress switches are used to make “Routing” decision

• No MAC learning required inside the L2 Fabric

Encapsulation to creates hierarchical address scheme

A C

S11 S42

CCAA

DATADATA

CCAA

DATADATA

TRILL/FabricPath Header

Ingress Switch

S11S11S42S42

Egress Switch

S11 � S42 TRILL/FabricPath Routing

L2 Bridging

A � C A � C

A � C


• Support more than 2 active paths (up to 16) across the Fabric• Increase bi-sectional bandwidth beyond port-channel• High availability with N+1 path redundancy

Forwarding decision based on ‘TRILL/FabricPath Routing Table’

A

L1L2

S1 S2 S3 S4

S11 S12 S42L2 FabricL2 FabricL3

L4

CA �

CA �

C A �C

A �C

Switch

IF… …S42 L1, L2, L3, L4

MAC IFA 1/1… …C S42 1/1


• Several ‘Trees’ are rooted in key location inside the fabric• All Switches in L2 Fabric share the same view for each ‘Tree’• Multicast traffic load-balanced across these ‘Trees’

Forwarding through distinct ‘Trees’

A

L2 FabricL2 Fabric

CA �

MA �

M A �M

A �M

Root for Tree #1

Root for Tree #2

Root for Tree #3

Root for Tree #4

Ingress switch for TRILL/ FabricPath decides which “tree” to be used and add tree number in the header

Ingress switch for TRILL/ FabricPath decides which “tree” to be used and add tree number in the header


• NHDA & NHSA are MAC addresses used to cross a legacy Ethernet Cloud

• V = Version• R = Reserved• M = Multi-destination• Opl = Option Length• Hop_Count = TTL• Egress Nickname = ODA• Ingress Nickname = OSA


• FabricPath bridges support multiple logical topologies over a single physical network, for example, by assigning different cost sets to the links

encoded Egress Bridge Nickname (ODA) encoded Ingress Bridge Nickname (OSA)

•Switch ID: Unique ID of each L2 Fabric device•Sub-Switch ID: to identify vPC+ pair (MC-LAG)•Tree ID: Unique ID of each distribution “Tree”

Tree ID = topology selector


TRILL FabricPath SPB (802.1aq ) OTV

Standard Yes (IETF, end 2010)

No (Cisco pre-standard TRILL)

Yes (IEEE, end 2011) IETF

Data Plane VLAN + TRILL header

VLAN-like header (upgradable to

TRILL)MAC Learning (QinQ, MAC-in-

MAC)IP

Outer MAC swapping hop-by-hop hop-by-hop end-to-end hop-by-hop

Loop Avoidance TTL TTL, RFP RPF TTL, RPF

Control Plane ISIS ISIS ISIS ISIS, PIM

Implementation 2011? 2010 2012? 2010IXP, Supercomputing MAN? DCI


32 Chassis

16 Chassis

16-way ECMP

8,192 10GE user ports per System512 10GE FabricPath ports per box

256 10GE FabricPath Ports

160 Tbps System Bandwidth(8K end-user 10GE ports)

Open I/O Slots for connectivity

Spine SwitchEdge Switch 16-port Etherchannel

FabricPathFabricPath

HPC Requirements • HPC Clusters require high-

density of compute nodes• Minimal over-subscription• Low server to server latency

FabricPath Benefits for HPC� FabricPath enables building a high-

density fat-tree network� Fully non-blocking with FabricPath

ECMP & port-channels � Minimize switch hops to reduce

server to server latencies


IXP Requirements � Layer 2 Peering enables multiple

providers to peer their internet routers with one another

� 10GE non-blocking fabric� Scale to thousands of portsFabricPath Benefits for IXP� Transparent Layer 2 fabric � Scalable to thousands of ports� Bandwidth not limited by chassis /

port-channel limitations� Simple to manage, economical to

build

Provider A Provider B

Provider C Provider D


MPLS-TPTransport Profile


Working LSP

PE PEProtect LSP

NMS for Network Management Control *

Client node Client node

MPLS-TP LSP (Static or Dynamic)Pseudowire

Client Signal

e2e and segment OAMSection Section

*Can use dynamic control plane (G.MPLS)

Connection Oriented, pre-determined working path and protect pathTransport Tunnel 1:1 or 1+1 protection, switching triggered by in-band OAM, NMS for static provisioning, optional control plane for routing and signaling


IP/MPLS MPLS-TP T-MPLS/PTNData Plane MPLS Forwarding MPLS Forwarding, with

- Bi-directional LSP- No PHP as default- No ECMP- Label 13 for OAM

MPLS-TP like forwarding,But:-- UsingUsing Label 14 for OAMLabel 14 for OAM(NOT interoperable w/ MPLS)(NOT interoperable w/ MPLS)

Control Plane MPLS, Routing, TE & GMPLS

- Static provisioning - NMS- GMPLS Control Plane

Static Only

OAM MPLS OAM Tools:-BFD (proactive)-LSP Ping (reactive)-VCCV

Extended MPLS OAM tools- New: AIS/RDI/LDI- New: Perforrmance Monitoring

Y.1731 (Ethernet ) OAM Y.1731 (Ethernet ) OAM with modification- Incomplete specification (NOT consistent w/ MPLS (NOT consistent w/ MPLS OAM)OAM)

Recovery Routing ProtocolsMPLS-TE Fast Reroute

1+1, 1:1 and 1:n Path/Segment, Linear & Ring protectionProtection triggered by OAM

Based on ITU-T SONET/SDH-style Automatic Protection Switching

IP/MPLS MPLS-TP T-MPLS/PTNCompatibility with IP/MPLS YES YES NOCompatibility with MPLS-TP YES YES NOEasy migration to MPLS-TP or IP/MPLS YES YES NOLTE suitable YES YES NO

Operational Impact:

Protocol Comparisons:


MPLS-TP Standards Update� 11 IETF RFCs published� 17 Working Group Drafts (4 in IETF editor’s Queue) � 35 Individual Drafts Active 20

08

History of T-MPLS and MPLS-TP

Huawei/ALU claim T-MPLS/PTN to be standards-based MPLS-TP, misleadingcustomers & creating market confusionCALL TO ACTIONCALL TO ACTION: : Effective Education of Customers

� T-MPLS/PTN is NOT MPLS-TP, and is STILL DEAD, it is not standards� T-MPLS/PTN will NOT interoperate or migrate to MPLS-TP or IP/MPLS

T-MPLS/PTN is not a standard!

Cisco Confidential 57© 2010 Cisco and/or its affiliates. All rights reserved. 57

• A generic OAM mechanism based on PW Associated Channel (ACH)• Generic Alert Label allow this to be applied to existing MPLS LSPs• OAM Requirements described in RFC5860

Alarms – LDI, RDI, AIS, APSProactive monitoring – BFD over LSP (eg. Cisco CPT has 3.3ms bfd hello)Reactive troubleshooting – ping/traceroute, loopback...Performance monitoring – loss, delay, jitter

L1 L2 ACH Channel Payload

0001 | Ver | Resv | Channel Type

ACH structure (RFC4385)

L1 L2 GAL/BoS Generic ACH Channel Payload

0001 | Ver | Resv | Channel Type

Generic ACH with Generic Alert Label


Multiservice CoreAggregation Edge CoreStatic MPLS-TP Access

IP/MPLS “Lite” Access

Ethernet Access

IP/MPLS “Lite” IP/MPLSIP/MPLS

L3 IP + Services PlacementCircuit Emulation + Ethernet

Aggregation Edge Core

Ethernet AccessStatic/Dynamic MPLS-TP IP/MPLSIP/MPLS

Static MPLS-TP Access

L3 IP + Services Placement


ACCESS / AGG.ACCESS / AGG.(Metro Transport)(Metro Transport)

AGGREGATIONAGGREGATION PREPRE--AGG.AGG. ACCESSACCESS(Mobile Backhaul)(Mobile Backhaul)

Next Generation

MWR

ME 3800X

ME 3600X

PRIME IP NGN PRIME IP NGN –– NMS/OSSNMS/OSS

CTM Support: CTM Support: Q1 2011Q1 2011

7600 ASR 9000

CPT50

CPT600

CPT200

UPD


• Technical Activities UpdateIETF Summary

• Fast ConvergenceIP Fast Reroute (FRR)BGP Protocol Independent Convergence (PIC)BGP Add-Paths

• New ProtocolsLISPTRILLMPLS-TP

Thank you.


Registrujte se za Cisco Live Networkers u Londonu ili Bahreinu!Više informacija na:http://www.ciscolive.com/


Documents

New Technologies in Routing (and Switching) - cisco.com · Presentation_ID © 2010 Cisco and/or its affiliates. All rights reserved. Cisco Confidential 3 “The mission of the IETF