Advanced Topics and Directions in - alcatron.net Live 2015 Melbourne/Cisco Live... · • Mobile Ad-hoc Networks (manet) • Multiprotocol Label Switching (mpls) ... • Traffic Engineering

BRKRST-3007 #clmel

Advanced Topics and Directions in Routing Protocols

BRKRST-3007

Alvaro Retana ([email protected])

Distinguished Engineer, Cisco Services

mailto:[email protected]

© 2015 Cisco and/or its affi liates. All rights reserved.BRKRST-3007 Cisco Public

© 2015 Cisco and/or its affi liates. All rights reserved. Cisco PublicBRKRST-3007

Agenda

• IETF Routing Review

– IETF Background

– The Routing Area and Routing-Related Work

• Secure Inter-Domain Routing

• Segment Routing

• The Internet Of Things (IoT)

IETF Routing Work



No one is in charge, anyone can

contribute and everyone can benefit.

The mission of the IETF is to produce high quality, relevant technical and engineering documents that influence the way people design, use, and manage the Internet in such a way as to make the Internet work better. These documents include protocol standards, best current practices, and informational documents of various kinds. “

RFC 3935

A Mission Statement for the IETF


IETF Meetings

Recent Meetings

• 89th IETF– March 2-7, 2014

– London, England

• 90th IETF

– July 20-25, 2014

– Toronto, ON, Canada

• 91st IETF

– November 9-14, 2014

– Honolulu, HI, USA

Upcoming Meetings

• 92nd IETF– March 22-27, 2015

– Dallas, TX, USA

• 93rd IETF

– July 19-24, 2015

– Prague, Czech Republic

• 94th IETF

– November 1-6, 2015

– Yokohama, Japan


http://w ww.arkko.com/tools/stats/areadistr.html

Work Distribution


Routing Area (rtg)...responsible for ensuring continuous operation of the Internet routing system by maintaining the scalability and stability characteristics of the existing routing protocols, as well as developing new protocols, extensions, and bug fixes in a timely manner.

• BGP Enabled Services (bess)

• Bidirectional Forwarding Detection (bfd)

• Bit Indexed Explicit Replication (bier)

• Common Control and Measurement Plane (ccamp)

• Forwarding and Control Element Separation (forces)

• Interface to the Routing System (i2rs)

• Inter-Domain Routing (idr)

• IS-IS for IP Internets (isis)

• Mobile Ad-hoc Networks (manet)

• Multiprotocol Label Switching (mpls)

• Network Virtualisation Overlays (nvo3)

• Open Shortest Path First IGP (ospf)

• Pseudowire And LDP-enabled Services (pals)

• Path Computation Element (pce)

• Protocol Independent Multicast (pim)

• Routing Over Low power and Lossy networks (roll)

• Routing Area Working Group (rtgwg)

• Service Function Chaining (sfc)

• Secure Inter-Domain Routing (sidr)

• Source Packet Routing in Networking (spring)

• Traffic Engineering Architecture and Signalling (teas)


Routing Area (rtg)

IP Routing• BGP Enabled Services (bess)






















Routing Area (rtg)

MPLS• BGP Enabled Services (bess)






















Routing Area (rtg)

SDN / Overlays• BGP Enabled Services (bess)






















Routing Area (rtg)

Mobility / Sensors• BGP Enabled Services (bess)






















Routing Area (rtg)

General• BGP Enabled Services (bess)





















© 2015 Cisco and/or its affi liates. All rights reserved.BRKRST-3007 Cisco Public 18

0

10

20

30

40

50

60

Nu

mb

er

of

Dra

fts

RTG Ongoing Work

Related

Official


Routing Area (rtg) - Focus...responsible for ensuring continuous operation of the Internet routing system by maintaining the scalability and stability characteristics of the existing routing protocols, as well as developing new protocols, extensions, and bug fixes in a timely manner.

• BGP Enabled Services (bess)






















Inter-Domain Routing

• RFCs Published in the Last Year

– Making Route Flap Damping Usable (rfc7196)

– The Accumulated IGP Metric Attribute for BGP (rfc7311)

– Enhanced Route Refresh Capability for BGP-4 (rfc7313)

• Active Drafts / Work Items

– Advertisement of Multiple Paths in BGP (draft-ietf-idr-add-paths)

– Best Practices for Advertisement of Multiple Paths in IBGP (draft-ietf-idr-add-paths-guidelines)

– Autonomous System (AS) Migration Features and Their Effects on the BGP AS_PATH Attribute (draft-ietf-idr-as-migration)

– Extended Message support for BGP (draft-ietf-idr-bgp-extended-messages)

– BGP Optimal Route Reflection (BGP-ORR) (draft-ietf-idr-bgp-optimal-route-reflection)

– BGP Custom Decision Process (draft-ietf-idr-custom-decision)

– Internet Exchange Route Server (draft-ietf-idr-ix-bgp-route-server)

– Accelerated Routing Convergence for BGP Graceful Restart (draft-ietf-idr-enhanced-gr)

– Revised Error Handling for BGP UPDATE Messages (draft-ietf-idr-error-handling)

– North-Bound Distribution of Link-State and TE Information using BGP (draft-ietf-idr-ls-distribution)

idr (BGP)

20


Global Routing Operations (OPS)

• ...consider the operational problems associated with the IPv4 and IPv6 global routing systems...


– Graceful BGP session shutdown (draft-ietf-grow-bgp-gshut)

– BGP Monitoring Protocol (draft-ietf-grow-bmp)

– Impact of BGP filtering on Inter-Domain Routing Policies (draft-ietf-grow-filtering-threats)

– IRR & Routing Policy Configuration Considerations (draft-ietf-grow-irr-routing-policy-considerations)

– Internet Exchange Route Server Operations (draft-ietf-grow-ix-bgp-route-server-operations)

– Operational Requirements for Enhanced Error Handling Behaviour in BGP-4 (draft-ietf-grow-ops-reqs-for-bgp-error-handling)

grow

21


Secure Inter-Domain Routing

• The two vulnerabilities that will be addressed are: – Is an Autonomous System (AS) authorised to originate an IP prefix?

– Is the AS-Path represented in the route the same as the path through which the NLRI traveled?


– Origin Validation Operation Based on the Resource Public Key Infrastructure (RPKI) (rfc7115)

– Resource Public Key Infrastructure (RPKI) Router Implementation Report (rfc7128)

– Threat Model for BGP Path Security (rfc7132)

– Policy Qualifiers in Resource Public Key Infrastructure (RPKI) Certificates (rfc7318)

– Security Requirements for BGP Path Validation (rfc7353)

sidr

25


Secure Inter-Domain Routing (2)


– BGPSec Considerations for AS Migration (draft-ietf-sidr-as-migration)

– BGP Algorithms, Key Formats, & Signature Formats (draft-ietf-sidr-bgpsec-algs)

– An Overview of BGPSEC (draft-ietf-sidr-bgpsec-overview)

– A Profile for BGPSEC Router Certificates, Certificate Revocation Lists, and Certification Requests (draft-ietf-sidr-bgpsec-pki-profiles)

– BGPSEC Protocol Specification (draft-ietf-sidr-bgpsec-protocol)

– Template for a Certification Practice Statement (CPS) for the Resource PKI (RPKI) (draft-ietf-sidr-cps)

– RPKI Repository Delta Protocol (draft-ietf-sidr-delta-protocol)

– RPKI Local Trust Anchor Use Cases (draft-ietf-sidr-lta-use-cases)

– Resource Certificate PKI (RPKI) Trust Anchor Locator (draft-ietf-sidr-rfc6490-bis)

– The Resource Public Key Infrastructure (RPKI) to Router Protocol (draft-ietf-sidr-rpki-rtr-rfc6810-bis)

– RPKI Validation Reconsidered (draft-ietf-sidr-rpki-validation-reconsidered)

– Securing RPSL Objects with RPKI Signatures (draft-ietf-sidr-rpsl-sig)

– Router Keying for BGPsec (draft-ietf-sidr-rtr-keying)

sidr

26


Prefix Hijack

Origin AS

AS x

10.0.0.0/22

Hijacker AS

10.0.0.0/24

Six worst Internet routing attacks :

http://www.networkworld.com/news/2009/011509-bgp-attacks.html


Solution Components

28

BGP Secure Origin AS

You only validate the Origin AS of a BGP UPDATE

Solves most frequent incidents (*)

No changes to BGP nor router’s hardware impact

Standardisation almost finished and running code

BGP PATH Validation

BGPSEC proposal under development at IETF

Requires forward signing ASPATH attribute

Changes in BGP and possible routers

(*) Ref: How Secure are Secure BGP Protocols, Sharon Goldberg, Microsoft Research & Boston University, NANOG 49

RPKI Infrastructure

Offline repository of verifiable secure objects based on public key cryptography

Follows resources (IPv4/v6 + ASN) allocation hierarchy to provide “right of use”


BGP Origin Validation

Origin AS

AS x

Hijacker AS

with unauthorised origin

10.0.0.0/22

10.0.0.0/24

Valid Origin

Invalid Origin

Certs


What is the Way Forward?

• Islands of Trust– Incremental Deployment

– Interconnections between Islands is a natural extension (archipelago).

• What is an Island of Trust?– Group of Autonomous Systems with common business/technical/service

goals.

– Technology deployment benefits all the members of the island.


RPKI Deployment State

http://rpki.surfnet.nl/perrir.html


Deployment at the NAP.EC

• Why Ecuador?

– Manageable community size (50+ Resource Holders)

– ~100% announcements of the address space in Ecuador

– Common business benefit: protect local traffic!

• Lessons Learned and Best Practices:

– Community training on the technology and its benefits and effects is vital.

– Multi-day “signing party” is needed.

– Technical and business owners must participate.

– Impromptu collaboration between competitors to resolve conflicts.

• Results

– Increased the value of the network services offered by the IXP and the country’s operators.

– Increased the confidence of local communications in critical services.


Home Networking (INT)

• ...focuses on the evolving networking technology within and among relatively small "residential home" networks.

• General Routing Requirements:

– knowledge of the homenet topology ... and that it can pass around more than just routing information

– inclusion of the PHY layer characteristics in path computation

– Multi-homing: Multiple upstreams, load-balancing to multiple providers, and failover from a primary to a backup link when available .. support multiple ISP uplinks and delegated prefixes in concurrent use.

– self-configuring ... determining the boundaries of the homenet.

• Reading List

– IPv6 Home Networking Architecture Principles (rfc7368)

– Home Networking Control Protocol (draft-ietf-homenet-hncp)

homenet

38


Open Shortest Path First


– Use of the OSPF-MANET Interface in Single-Hop Broadcast Networks (rfc7137)

– Supporting Authentication Trailer for OSPFv3 (rfc7166)


– OSPF Extensions to Support Maximally Redundant Trees (draft-ietf-ospf-mrt)

– Advertising per-node administrative tags in OSPF (draft-ietf-ospf-node-admin-tag)

– OSPFv3 Auto-Configuration (draft-ietf-ospf-ospfv3-autoconfig)

– OSPFv3 LSA Extendibility (draft-ietf-ospf-ospfv3-lsa-extend)

– OSPFv3 Extensions for Segment Routing (draft-ietf-ospf-ospfv3-segment-routing-extensions)

– Extensions to OSPF for Advertising Optional Router Capabilities (draft-ietf-ospf-rfc4970bis)

– OSPF Traffic Engineering (TE) Metric Extensions (draft-ietf-ospf-te-metric-extensions)

– OSPFv3 over IPv4 for IPv6 Transition (draft-ietf-ospf-transition-to-ospfv3)

– OSPF Topology-Transparent Zone (draft-ietf-ospf-ttz)

– OSPF Two-part Metric (draft-ietf-ospf-two-part-metric)

ospf

39


OSPFv3 Auto-Configuration

• Configuration Defaults1. Area 0 Only

2. OSPFv3 SHOULD be auto-configured on all IPv6-capable interfaces.

3. OSPFv3 interfaces will be auto-configured to an interface type corresponding to their layer-2 capability.

4. OSPFv3 interfaces MAY use an arbitrary HelloInterval and RouterDeadInterval

5. All OSPFv3 interfaces SHOULD be auto-configured to use an Interface Instance ID of 0 that corresponds to the base IPv6 unicast address family instance ID.

40


OSPFv3 LSA Extendibility

• Extends the LSA format by allowing the optional inclusion of TLVs.

draft-ietf-ospf-ospfv3-lsa-extend

41

0 1 2 3

0 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+-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| LS Age |1|0|1| 0x21 |+-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| Link State ID |+-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| Advertising Router |+-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| LS Sequence Number |+-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| LS Checksum | Length |+-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| 0 |Nt|x|V|E|B| Options |

+-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+. .. TLVs .. .+-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Extended Router-LSA


IS-IS for IP Internets


– Reclassification of RFC 1142 to Historic (rfc7142)

– Transparent Interconnection of Lots of Links (TRILL) Use of IS-IS (rfc7176)

– IS-IS Flooding Scope Link State PDUs (LSPs) (rfc7356)

– Updates to IS-IS TLV Codepoints Registry (rfc7370)


– IS-IS Extended Sequence number TLV (draft-ietf-isis-extended-sequence-no-tlv)

– Intermediate System to Intermediate System (IS-IS) Extensions for Maximally Redundant Trees (MRT) (draft-ietf-isis-mrt)

– Advertising Per-node Admin Tags in IS-IS (draft-ietf-isis-node-admin-tag)

– IS-IS Route Preference for Extended IP and IPv6 Reachability (draft-ietf-isis-route-preference)

– Advertising S-BFD Discriminators in IS-IS (draft-ietf-isis-sbfd-discriminator)

– IS-IS Extensions for Segment Routing (draft-ietf-isis-segment-routing-extensions)

– IS-IS Traffic Engineering (TE) Metric Extensions (draft-ietf-isis-te-metric-extensions)

– YANG Data Model for ISIS protocol (draft-ietf-isis-yang-isis-cfg)

isis

42


Routing Area WG

• Updated Charter:

– Venue to discuss, evaluate, support and develop proposals for new work in the Routing Area.

– Enhancements to hop-by-hop distributed routing related to fast-reroute and loop-free convergence.

– Routing-related YANG models.


– Requirements for Advanced Multipath in MPLS Networks (rfc7226)


– Use of BGP for routing in large-scale data centres (draft-ietf-rtgwg-bgp-routing-large-dc)

– IP MIB for IP Fast-Reroute (draft-ietf-rtgwg-ipfrr-ip-mib)

– Operational management of Loop Free Alternates (draft-ietf-rtgwg-lfa-manageability)

– Multicast only Fast Re-Route (draft-ietf-rtgwg-mofrr)

– Algorithms for computing Maximally Redundant Trees for IP/LDP Fast- Reroute (draft-ietf-rtgwg-mrt-frr-algori thm)

– An Architecture for IP/LDP Fast-Reroute Using Maximally Redundant Trees (draft-ietf-rtgwg-mrt-frr-architecture)

– Remote LFA FRR (draft-ietf-rtgwg-remote-lfa)

– Remote-LFA Node Protection and Manageability (draft-ietf-rtgwg-rlfa-node-protection)

rtgwg

43


Remote LFA FRR

• Some topologies, notably ring based topologies are not well protected by LFAs alone.

• Remote LFAs benefits: – simplicity,

– incremental deployment

– good protection coverage.

draft-ietf-rtgwg-remote-lfa

44

B

D E

C

A

F


Source Packet Routing in Networking

• ...procedures that will allow a node to steer a packet along an explicit route using information attached to the packet and without the need for per-path state information to be held at transit nodes.


– IPv6 SPRING Use Cases (draft-ietf-spring-ipv6-use-cases)

– SPRING Problem Statement and Requirements (draft-ietf-spring-problem-statement)

– Use-cases for Resiliency in SPRING (draft-ietf-spring-resiliency-use-cases)

– Segment Routing Architecture (draft-ietf-spring-segment-routing)

• Reading Material

– Segment Routing Centralised Egress Peer Engineering (draft-filsfils-spring-segment-routing-central-epe)

– Segment Routing interoperability with LDP (draft-filsfils-spring-segment-routing-ldp-interop)

– Segment Routing with MPLS data plane (draft-filsfils-spring-segment-routing-mpls)

– Topology Independent Fast Reroute using Segment Routing (draft-francois-spring-segment-routing-ti-lfa)

– IPv6 Segment Routing Header (SRH) (draft-previdi-6man-segment-routing-header)

spring

45


Segment Routing

• Source routing based on the notion of a segment

• A 32-bit segment can represent any instruction– Service

– Context

– IGP-based forwarding construct

– Locator

• Ordered list of segments

– An ordered chain of topological and service instructions

• Per-flow state only at ingress SR edge node

– Ingress edge node pushes the segment list on the packet


Segment Routing

• Forwarding state (segment) is established by IGP

– LDP and RSVP-TE are not required

– Agnostic to forwarding dataplane: IPv6 or MPLS

• MPLS Dataplane is leveraged without any modification

– push, swap and pop: all that we need

– segment = label

• IPv6 Dataplane leverages simple extension header

• Source Routing

– source encodes path as a label or stack of segments

– two segments: prefix (node) or adjacency


Adjacency Segment

• C allocates a local label

• C advertises the adjacency label in ISIS or OSPF

– simple sub-TLV extension

• C is the only node to install the adjacency segment in MPLS dataplane

A B C

M N O

Z

D

P

Pop

9003

A packet injected at

node C with label

9003 is forced

through datalink CO

65


A Path with Adjacency Segments

• Source routing along any explicit path– stack of adjacency labels

• SR provides for entire path control

B C

N O

Z

D

P

A

9101

9105

9107

91039105

9101

9105

9107

9103

9105

9105

9107

9103

9105

9107

9103

9105

9103

9105

9105


Prefix (Node) Segment

• Z advertises its node segment

– simple ISIS sub-TLV extension

• All remote nodes install the node segment to Z in the MPLS dataplane

A B C

Z

D

65

FEC Z

push 65

swap 65

to 65

swap 65

to 65pop 65

A packet injected

anywhere with top

label 65 will reach Z

via shortest-path


Combining Segments

• Source Routing

• Any explicit path can be expressed: ABCOPZ

A B C

M N O

Z

D

P

Pop

9003

Packet to Z

65

9003

Packet to Z

65

Packet to Z

Packet to Z

65

Packet to Z

65

9003

72

Packet to Z

65

9003

72

7272

65

65


IGP Automatically Installs Segments

• Simple extension

• Excellent Scale: a node installs N+A FIB entries– N node segments and A adjacency segments

A B C

M N O

Z

D

P

Nodal segment to C

Nodal segment to Z

Adj Segment

Nodal segment to C


Application Controls – Network Delivers

• The network is simple, highly programmable and responsive to rapid changes– The controller abstracts the network topology and traffic matrix

– Perfect support for centralised optimisation efficiency, if required

2G from A to Z please

Link CD is full, I cannot use the

shortest-path 65 straight to Z

65FULL

65


Application Controls – Network Delivers

• The network is simple, highly programmable and responsive to rapid changes

Path ABCOPZ is ok. I account the BW.

Then I steer the traffic on this path

FULL66

65

68

Path AZ onto {66, 68, 65}


Segment Routing

• Simple to deploy and operate– Leverage MPLS services & hardware

– straightforward ISIS/OSPF extension

• Provide for optimum scalability, resiliency and virtualisation

• Perfect integration with application

• EFT and IETF available – test and contribute


Bit Indexed Explicit Replication

Challenge

• Complex Control Plane

– PIM has many modes and corner cases requiring specialised expertise to deploy, troubleshoot, and maintain

• State Impacted Convergence

– More trees results in slower network convergence times

– PIM adds tree state for every application flow

• Receiver Driven Paths

– Multicast often takes an unexpected, different path than unicast

bier

65


Bit Indexed Explicit Replication (2)

Solution

• No Multicast Flow State

– Multi-point unicast reachability

• No Multicast Tree-building Control Plane

• Fast Convergence

– Unicast convergence times

• No unwanted traffic in MVPN

– True explicit replication

– No trade-off between unwanted traffic or excessive state

• No Data-Driven Events

bier

66


Routing Over Low Power and Lossy Networks

• Focused on routing issues for low power and lossy networks.

• Reading List– RPL: IPv6 Routing Protocol for Low-Power and Lossy Networks (rfc6550)

– Routing Metrics Used for Path Calculation in Low-Power and Lossy Networks (rfc6551)

– Objective Function Zero for the Routing Protocol for Low-Power and Lossy Networks (RPL) (rfc6552)

– Terminology in Low power And Lossy Networks (draft-ietf-roll-terminology)

– Multicast Protocol for Low power and Lossy Networks (MPL) (draft-ietf-roll-trickle-mcast)

roll

69


What is a Low Power Lossy Network (LLN)?

• LLNs comprise a large number of highly constrained devices (smart objects) interconnected by predominantly wireless links of unpredictable quality

• LLNs cover a wide scope of applications

– Industrial Monitoring, Building Automation, Connected Home, Healthcare, Environmental Monitoring, Urban Sensor Networks, Energy Management, Asset Tracking, Refrigeration

World’s smallest web server


Characteristics of Internet vs Smart Object Networks

Current Internet Smart Object Networks

Nodes are routers Nodes are sensor/actuators and routers

IGP with typically few hundreds of 100 nodes An order of magnitude larger in nodes

Links and Nodes are stable Links are highly unstable Nodes fail more frequently

Node and link bandwidth constraints are generally

non-issuesNodes & links are high constrained

Routing is not application awareApplication-aware routing, in-Band processing is a

MUST


RPL Terminology

5

3

5

4

RPL Instance Consists of one or more DODAGssharing SAME service type (Objective Function)

Identified by RPL INSTANCE ID

UP (D

AO

Messages)

DODAG Root

Identif ied by DODAG ID

(Node IPv6 address)

Direction Oriented DAG (DODAG)Comprises DAG with a single root

Rank

Tow

ard

s D

OD

AG

Root

Rank = n

Rank < n

Node

(OF configured)

2

5

4

3

3

Rank d

ecre

ases

DODAG parent

to child “5”s

2

DODAG Root

Rank is alw ays “1”

(Typically an LBR - LLN Border Router)

3

2

Sub-DODAG

DODAG

DO

WN

(D

IO M

essages)

Tow

ard

s

DO

DA

G l

eafs

Rank > n

Rank = n

Rank

incre

ases

Non-LLN Netw ork

(IPv6 Backbone)

Siblings

44

DODAG

Sensor Node

1 1


RPL Supported Traffic Flows

IPv6IPv6IPv6

• Multipoint to Point

‒ DIO messages

5

3

5

4

2

1

5

4

3

2

DODAG RootUPw

ard

sro

ute

s

DO

WN

ward

sro

ute

s

• Point to Multipoint

DAO messages• Point to Point

Storing Mode, DAO

Fully Stateful

5

3

5

5

2

1

5

5

3

2

DODAG Root

5

3

5

4

2

1

5

4

3

2

DODAG Root

Subset of devices

IPv6

5

3

5

4

2

1

5

4

3

2

DODAG Root

• Point to Point

Non-Storing Mode, DAO

Source routed to root


DODAG Neighbours and Parent SelectionGeographic Layout

Set ofCandidate Neighbours

Set ofParents

Preferred Parent

• Upward route discovery

Comprises three logical

sets of link-local nodes

Neighbours are learnt from

DIO advertisements

IPv6

Core

IPv6

Core

IPv6

Core

Candidate neighbour Set Parent Set Preferred Parent

Subset of nodes reachable via

link-local multicast

Consists of nodes with a higher

rank (lower #)

Preferred next-hop to

the DODAG Root

Elements in the set MAY belong

to different DODAG versions

Elements in the set MUST

belong to SAME DODAGversion

Multiple preferred

parents possible if ranks are equal

IPv6

Core


RPL Summary

• RPL is a foundation of the Internet of Things– Open standard to meeting challenging requirements

• Promising technology to enable IP on many billions of smart objects

• Very compact code

– Supports wide range of media and devices

• Cisco Implementation

– Incorporated into Cisco Grid Blocks Architecture

– Available on Cisco CGR1000 series routers (indoor and poletop outdoor)


Summary

• More than 20 IETF WGs produced significant routing protocol work this last year.

– The requirements on routing protocols are coming from a diverse set of sources: from the Internet of Everything, traditional SP and Enterprise networks, to SDN and beyond.

• Routing Protocols are mature, but entering a new era of increased, dynamic coverage.

– Convergence, Availability, Scalability and Security are still front and centre, but with new requirements in new environments.

What should the future bring?

Q & A


Give us your feedback and receive a

Cisco Live 2015 T-Shirt!

Complete your Overall Event Survey and 5 Session

Evaluations.

• Directly from your mobile device on the Cisco Live

Mobile App

• By visiting the Cisco Live Mobile Site

http://showcase.genie-connect.com/clmelbourne2015

• Visit any Cisco Live Internet Station located

throughout the venue

T-Shirts can be collected in the World of Solutions

on Friday 20 March 12:00pm - 2:00pm

Complete Your Online Session Evaluation

Learn online with Cisco Live! Visit us online after the conference for full

access to session videos and

presentations. www.CiscoLiveAPAC.com

http://showcase.genie-connect.com/clmelbourne2015

http://www.ciscoliveapac.com/

Documents

Advanced Topics and Directions in - alcatron.net Live 2015 Melbourne/Cisco Live... · • Mobile Ad-hoc Networks (manet) • Multiprotocol Label Switching (mpls) ... • Traffic Engineering