Always on visibility: In-band OAM for IPv6

Transcription

1

2 Always on visibility: In-band OAM for IPv6 A trip-recorder for your traffic at line rate performance Frank Brockners BRKRST-2606

3 Today s Role Of A Network Engineer

4 Enhanced Visibility And Diagnostics

5 On-Board Unit Speed control by police car Diagnostics: Built-in or Probe-Based?

6 The Need The Technology The Solutions IP OAM overview and use-case for in-band OAM In-band OAM for IPv6: Technology and proof-of-concept implementation Leveraging the new data-sources: Flow-tracing data Proof-of-work data Generic meta data

7 OAM Operations, Administration, Maintenance Introduction and Overview to IP OAM

8 What is OAM: IETF Definition (RFC 6291) Operations: Operational activities to keep network up and running. E.g. Monitoring, finding faults Administration: Involves keeping track of network resources. E.g. Bookkeeping, (available ports, BW) Maintenance: Involves repair and upgrades. E.g. Software upgrades, configurations, corrective and preventive measures.

9 Things that people associate with OAM Continuity Check Ability of endpoint to monitor liveliness of a path (e.g. BFD ) Connectivity Verification Ability of an endpoint to verify it is connected to a specific endpoint (e.g. BFD, ping) Route/Path Tracing and Verification Identify and verify the path taken from one from one Maintenance End Point (MEP) to another to another MEP via a set of Maintenance Intermediate Points (MIP) ( traceroute ) Fault Verification Exercised on demand to validate the reported fault. (e.g. Ping) Fault Isolation Localizing and isolating the failure domain/point (e.g. traceroute) Performance Includes Packet Loss Measurements and Packet Delay Measurements E.g. IP Performance Metrics (IPPM) (RFC 2330)

10 How to send OAM information in packet networks? In-band OAM OAM traffic embedded in the data traffic but not part of the payload of the packet OAM effected by data traffic Example: IPv4 route recording Out-of-band OAM OAM traffic is sent as dedicated traffic, independent from the data traffic ( probe traffic ) OAM not effected by data traffic Examples: Ethernet CFM (802.1ag), Ping, Traceroute Note the difference to transport OAM (SDH/SONET): In SONET/SDH there is a constant flow of frames OAM is a bit-stream/data between the data encoding sublayer and the physical media and present in every frame, but not part of the data payload This mode of OAM transport is often referred to as out of band, because OAM has it s own channel but still resides side by side with the payload data (if present)

11 Remember SDH? Bit Error Monitoring. The B1 Byte contains the result of the parity check of the previous STM frame, after scrambling of the actual STM frame. This check is carried out with a Bit Interleaved Parity check (BIP-8). regenerator section overhead multiplex section overhead Payload Bit Error Monitoring. The B2 Bytes contains the result of the parity check of the previous STM frame, except the RSOH, before scrambling of the actual STM frame. This check is carried out with a Bit Interleaved Parity check (BIP24) J0: Path Trace. It is used to give a path through an SDH Network a "Name". This message (Name) enables the receiver to check the continuity of its connection with the desired transmitter. (Note: J0 not shown in diagram here)

12 Remember RFC 791?

13 Challenges with OAM for IP Original OAM tools (ping, traceroute) were designed for unicast traffic with a single path to the destination and with the assumption in mind that all traffic is forwarded the same way Today ECMP (Equal Cost Multi Path) Routers/Switches have different packet processing paths for different types of traffic Multicast Tunneling Middle-boxes (Firewalls, ) Misconfigurations (intentional and unintentional)

14 Spotlighting Equal Cost Multipath Equal Cost Multi Path (ECMP) allows Protection against failures Increased overall end-end bandwidth ECMP is popular Devices typically use fields in the MAC or IP header to select the forwarding path among multiple equal cost paths Connectivity and Continuity verification messages should follow the same path and be forwarded the same way as user data in order to be useful How can we accomplish this? There is no standard way of doing this in IP world

15 ECMP Ping from A to B UDP User Data from A/port a to B/port b A B UDP User Data from A/port x to B/port y

16 ECMP and Failure Detection Ping from A to B UDP User Data from A/port a to B/port b A B UDP User Data from A/port x to B/port y

17 ECMP Monitoring Challenges Ingress Node (A) may not even know how many ECMP from intermediate node Monitoring/probe traffic ( ping ) SHOULD take the same path as the normal data Different vendors utilize different hash algorithms in selection ECMP paths Different platforms utilize different hash algorithms in selection ECMP paths Do you always know how each intermediate device s hash function? Can you craft your probe traffic accordingly? Monitoring/probe traffic ( ping ) SHOULD be forwarded like normal data traffic Ping often handled in the process path (especially extended ping).

18 Spotlighting: Service Chain Integrity Company requires proof that packets of a certain application were forwarded and processed per the company's security policy. Examples: Packets for application A have to be received from a pair of border routers X and Y Packets for application B have to be processed by Firewall FW1 or FW2 and Web Security Appliance (WSA) If a packet flow is supposed to go through a series of service functions, it has to be proven that all packets of the flow actually went through the service chain per the company's policy. Different service chaining technologies Chaining through interface or VLAN stitching Network Service Header (NSH), Segment Routing (SR), LISP

19 Service Chain Integrity Service Chain: A B C Service A Service B Service C In policy Out of policy

20 Proving Service Chain Integrity: Approaches Indirect proof: Service appliances and network forwarding are in different trust domains. Physical hand-off-points are defined between these trust domains (i.e. physical interfaces) Applies well to service chains with physical appliances Direct proof: Carry a secure proof in the packet that a service chain was traversed Generally applicable (incl. NFV, single trust domains, etc.) Trust Domain 1 (e.g. appliances) Service A Service B Trust Domain 2 (e.g. network) Inter-domain service handoff point

21 Amending the OAM capabilities of IP Capability Existing Tools Additions Continuity Check Connectivity Verification Path Discovery and Verification Defect Indications Performance Monitoring BFD Ping / ICMP echo Traceroute IPPM (delay/packet loss) Light-weight continuity check (check without sending extra traffic) EMCP support Acknowledge different packet forwarding paths in routers EMCP support Acknowledge different packet forwarding paths in routers Prove correctness/integrity of forwarding path Indicate if a forwarding policy (service chain) has not been met Metrics for live data traffic (delay, packet loss)

22 What if you had a trip recorder for your packets? Use-cases of enhanced IP OAM

23 Example Use-Cases Debugging networks with ECMP Derive Network Traffic Matrix R1 R4 R2 R5 R3 R6 R1 R2 R3 R4 R5 R6 R R R R Probe packet tests the wrong path R R

24 Example Use-Cases Delay measurements and trend analysis Link 3 Service Chain Validation Link 1 Link 2 Link 4 Service Chain: A B Delay Link1 Delay Link2 Delay Link3 Delay Link4 t = 1 1.2ms 14.8ms 3.8ms 24.8ms Service A Service B In policy: Forward t = 2 1.2ms 14.8ms 3.8ms 24.8ms t = 3 1.2ms 14.7ms 3.8ms 24.7ms t = 4 1.2ms 14.8ms 3.8ms 24.8ms t = 5 1.2ms 14.8ms 3.8ms 24.8ms t = 6 1.2ms 17.8ms 3.8ms 24.7ms Out of policy: Drop t = 7 1.2ms 17.9ms 3.8ms 24.7ms t = 8 1.2ms 18.1ms 3.8ms 24.8ms

25 Example Use-Cases Gathering User-Defined OAM Information: Location Gathering User-Defined OAM Information 70% 100% 5% 20% Example: Flow tracing across a network with moving devices: Detect areas of which have higher delay, high loss probability, etc. Example: Charge level for battery-operated devices

26 In-Band OAM for IPv6 (ioam6) Network provided telemetry data gathered and added to live data traffic: New sources of data for SDN applications

27 Approach: Add OAM information into every packet Gather information along the path in IPv6 extension header In-band OAM for IPv6 (ioam6) information carried in IPv6 extension header Restrict use to a specific domain Domain-ingress, domain-egress, and select devices within a domain insert/remove/update the extension header Information export via IPFIX/Flexible-Netflow Packets with ioam6 option handled in the fast-path of a router Apps/Controller Flexible set of data carried in ioam6 header Proof of work data Edge-to-edge data Tracing data Network Element v6 traffic matrix Verify Service Chain Live flow tracing Loss matrix/ monitor Delay distribution App data monitoring Enhanced Telemetry Per hop and end-to-end data added to (selected) data traffic into the packet Node-ID Ingress i/f egress i/f Sequence# Timestamp App-Data

28 IPv6 Extension Headers recap The base IPv6 standard (RFC2460) defines extension headers An expansion mechanism to carry optional internet layer information Key differentiator to IPv4 Example extension headers Hop-by-Hop Options, Routing, Fragment, Destination Options, Authentication, Encapsulating Security Payload, MIPv6, HIP, shim6 Current discussion on clarifying HbyH header (to update RFC2460): draft-baker-6man-hbh-headerhandling IPv4 Header IPv6 Header Next Header Next Header Next Header Layer 4 Header Extension Header 1 Extension Header.. Extension Header n Layer 4 Header

29 Life of ioam6 extension header From ioam6 domain edge to edge ioam6 domain IPv6 Payload IPv6 Packet flow Add ioam6 header + ioam IPv6 ioam Update ioam6 header Payload IPv6 ioam Payload Remove ioam6header Optional: Export IPFIX - ioam IPv6 Payload Header Proof of work data Tracing Data Edge to Edge data

30 ioam6 Example: Path-Tracing (Node-ID and Egress I/F) B 3 6 v6 Hdr Payload A v6 Hdr 1 2 C 4 v6 Hdr 5 v6 Hdr D v6 Hdr Payload B 6 C 4 A 1 Payload C 4 A 1 Payload A 1 Payload

31 In-band OAM for IPv6 (ioam6) Header discussion Scope (which nodes) Edge-to-edge of a domain (per packet sequence numbers e.g. for traffic matrix) Specific nodes within a domain (e.g. service forwarders for service chain verification) Specific sets of nodes within a domain (e.g. all routers in the part of the network that leverages ECMP) Types of data required for different use-cases Proof of work data Data inserted and updated by a set of nodes. Set of nodes is known to the domain ingress device. Data is inspected by domain egress device. Edge-to-edge data Data inserted by the domain ingress device and inspected and removed by the domain egress device Tracing data Data (or subset of data) is inserted by the domain ingress device and added to or updated by devices in the domain that support the ioam6 tracing capability. The header is inspected and removed by the domain egress device.

32 ioam6 Extension Header: Types of Fields Per node scope Hop-by-Hop information processing Device_Hop_L Node_ID Ingress Interface ID Egress Interface ID Time-Stamp Application Meta Data Set of nodes scope Hop-by-Hop information processing Service Chain Validation (Random, Cumulative) End to end scope End-to-End information processing Sequence Number

33 ioam6 in IPv6 Extension Header OAM Type: 8-bit identifier of a particular OAM variant. Rec Pointer: It contains the index, in the Data Space, of the next Node data to populate. Rec pointer is decremented at each node and it is used as an index in the Node data List. Max node data: Maximum number of node data items the Node data List can grow to Total node data: Total number of node data items in the Node data List Flags: 8-bit unsigned integer. Currently 0x1 means that POW Data is present. Node data: Variable-length field, of format determined by the OAM Type OAM Type Rec Pointer flags Max_node_data Total nodedata reserved <-+ Random number P Random number (contd) O W Cumulative Cumulative (contd) <-+ Node data List [0] D a Node data List [1] t a S p a Node data List [n-1] c e Node data List [n] <-+ OAM Option(s)

34 Edge to Edge data Tracing Data Proof of work data header ioam6 Extension Header: Properties and Use-Cases OAM Type Rec Pointer flags Max_node_data Total nodedata reserved Random Random (contd.) Cumulative Cumulative (contd) Node data n Node data n Node data Node data OAM Option(s) Use Cases Service Chain Verification ECMP Flow tracing, Network-Delay Trends, Traffic Matrix Per flow statistics Property Updated at subset of nodes: Only service nodes update proof of work Updated at each hop or subset of all nodes: ECMP flow tracing Only at nodes participating in ECMP would rewrite Network-Delay Trends All the nodes in the ioam domain Traffic Matrix Only ingress node Added at ingress edge, no updates at any node

35 In-Band OAM for IPv6: Proving the concept

36 ioam6: Implementation Approach In-band OAM mechanisms for IP (route recording) have been proposed in the past, but were always received with skepticism Performance concerns Footprint for a new technology (incl. new packet header) vs. installed base: Is there a sufficiently large greenfield network to allow for the change? Deployment starting point for in-band OAM for IPv6 IoT networks, Data-Center Networks, greenfield network deployments Let s stop arguing and go try: Prototype implementation to prove concerns right or wrong

37 Prototype Setup Overview - Concept Demo Apps ioam APIs DB NetFlow Collector ioam6 domain Add ioam6 header Update ioam6 header Optional: Export IPFIX Remove ioam6header Optional: Export IPFIX

38 ioam6 Test Drive Basic configuration ipv6 ioam path-record ipv6 ioam node-id <node id> R7 ::b:1:0:0:7 node-id 7 R5 ::b:1:0:0:5 node-id 5 R8 ::b:1:0:0:8 node-id 8 R6 ::b:1:0:0:6 node-id 6

39 ioam6 Test Drive Extended Ping R5#ping Protocol [ip]: ipv6 Target IPv6 address: ::b:1:0:0:8 Repeat count [5]: Datagram size [100]: Timeout in seconds [2]: Extended commands? [no]: y Source address or interface: UDP protocol? [no]: Verbose? [no]: Precedence [0]: DSCP [0]: Include hop by hop Path Record option? [no]: y Sweep range of sizes? [no]: % Using size of 296 to accomodate extension headers ingress i/f node-id egress i/f Type escape sequence to abort. Sending 5, 296-byte ICMP Echos to ::B:1:0:0:8, timeout is 2 seconds: (Gi0/1)7(Gi0/2) (Gi0/1)8(Gi0/2) (Gi0/2)6(Gi0/1)! (Gi0/1)7(Gi0/2) (Gi0/1)8(Gi0/2) (Gi0/2)6(Gi0/1)! (Gi0/1)7(Gi0/2) (Gi0/1)8(Gi0/2) (Gi0/2)6(Gi0/1)! (Gi0/1)7(Gi0/2) (Gi0/1)8(Gi0/2) (Gi0/2)6(Gi0/1)! (Gi0/1)7(Gi0/2) (Gi0/1)8(Gi0/2) (Gi0/2)6(Gi0/1)! Success rate is 100 percent (5/5), round-trip min/avg/max = 4/6/10 ms R5 ::b:1:0:0:5 node-id 5 R7 ::b:1:0:0:7 node-id 7 R6 ::b:1:0:0:6 node-id 6 R8 ::b:1:0:0:8 node-id 8

40 ioam6 Test Drive A glimpse at ioam6 commands R5#sh ipv6 ioam? app-metadata IPv6 ioam Application Metadata summary flow-debug-summary IPv6 ioam flow debug summary interface IPv6 ioam Interface configuration and status node-id IPv6 ioam Node Id path-packet-counter IPv6 ioam PPC path-record IPv6 ioam Path Record pr6-link-id IPv6 ioam Link Id profile IPv6 ioam profile sfc-statistics IPv6 ioam Service Funvtion Chaining Statistics traffic-stats IPv6 ioam Traffic Statistics Output modifiers <cr> R5#sh ipv6 ioam interface IPv6 ioam enabled on following interfaces : Interface LinkID Profile\Encap\Decap Encap-Count Decap-Count ====================================================================== GigabitEthernet0/0 2 none\yes\no 0 0 GigabitEthernet0/1 3 none\yes\no GigabitEthernet0/2 4 none\yes\no GigabitEthernet0/3 5 none\yes\no GigabitEthernet0/4 6 none\yes\no 839 0

41 Early Performance Test Results IPv6 in-band OAM with no performance degradation IXIA (TX) Encap Transit Decap R1 ISR 3945 R2 ISR 3945 R3 ISR 3945e CPU Utilization in % at 600Mbps/no drops/imix traffic IXIA (RX) Testcase Encap (R1) Forward (R2) Decap (R3) CEF GRE+IPV ioam6 (for all traffic)

42 In-Band OAM for IPv6: Leveraging Flow-Tracing Information

43 Flow Tracing in EMCP Networks Probe packet ( ping ) tests the wrong path Trace all paths and detect the one with issues

44 ioam6 Extension Header: Node data for ioam6 Type 0 Node data is hop by hop focused hop_limit node_id ingress_if_id egress_if_id timestamp app_data hop_limit: node_id: ingress_if_id: egress_if_id: timestamp: app_data: Hop/TTL value of the packet at the node recording this. Identification id of the node. Interface id on which this packet has been received. Interface id from which this packet has been sent. Time when ioam6 packet has been received at this node. Placeholder which can be used by this node to add application specific data/metadata.

45 ioam per flow loss statistics using Sequence Numbers Identify transmission problems along a specific path Sender Receiver Sequence number Detection: Packet #3 lost Identify whether packets were lost (or even added) along a specific path (assuming there is only a single path from sender to receiver) Identify which packets were lost or added Network Sent counter: 2137 Receive counter: 2136, Lost: 1 No need to timestamp packets to keep counters between sender and receiver in synch

46 ioam6 Extension Header OAM Option Format Opt Type Opt Len Option data OAM Options are Edge to Edge focused Options defined so far: Sequence Number: Type = 1, Length = 4; 4 Bytes of Data.

47 ioam6 Test Drive Path Packet Counters Encapsulation (R5) R5#sh ipv6 ioam path-packet-counter Profile p1: Path Packet Counter Enabled: PPC analyze ACL : acl1, refcount 2 1 permit ipv6 ::A:1:1:0:5:/128 ::A:1:1:0:D:/128 Current PPC : 11 Total Tx pkts : 10 2 permit ipv6 ::A:1:1:0:5:/128 ::B:1:0:0:3:/128 Current PPC : 1 Total Tx pkts : 0 3 permit ipv6 ::B:1:0:0:1:/128 ::A:1:1:0:5:/128 Current PPC : 1 Total Tx pkts : 0 4 permit ipv6 ::B:1:0:0:1:/128 ::B:1:0:0:3:/128 Current PPC : 12 Total Tx pkts : 11 FNF collector disabled for the profile R5# Decapsulation (R8) R8#sh ipv6 ioam path-packet-counter Profile p1: Path Packet Counter Enabled: PPC analyze ACL : acl1, refcount 2 1 permit ipv6 ::A:1:1:0:5:/128 ::A:1:1:0:D:/128 Rx statistics: Total Rx Packets 105 lost packets 10 Reordered packets 0 duplicate packets 0 Highest Seq Recvd permit ipv6 ::A:1:1:0:5:/128 ::B:1:0:0:3:/128 Rx statistics: Total Rx Packets 0 lost packets 0 Reordered packets 0 duplicate packets 0 Highest Seq Recvd 0 3 permit ipv6 ::B:1:0:0:1:/128 ::A:1:1:0:5:/128 Rx statistics: Total Rx Packets 0 lost packets 0 Reordered packets 0 duplicate packets 0 Highest Seq Recvd 0 4 permit ipv6 ::B:1:0:0:1:/128 ::B:1:0:0:3:/128 Rx statistics: Total Rx Packets 16 lost packets 13 Reordered packets 0 duplicate packets 0 Highest Seq Recvd 29 R8#

48 Demo Setup VIRL (Virtual Internet Routing Lab) ioam6 enabled IOSv image pmacct as Netflow collector (open source) mysql data base (open source) Apps with NeXT UI for visualization Apps (Visualization with NeXT UI) ioam6 API Database (mysql) Netflow Collector (pmacct) ioam6 domain Demo Setup in VIRL

49

50 ECMP Flow Tracing Path 1

51 ECMP Flow Tracing Flow 2

52 Example: Deriving the traffic matrix using ioam6 Desired outcome Show total traffic between any two edge routers of a domain for a given time interval as a matrix Show total traffic per link for a given time interval (average bandwidth) Approach Enable ioam6 for all flows for the entire domain and record: Node id and Egress Interface Statistics similar to stats per FEC for an MPLS network at a PE Egress Edge routers aggregate stats of individual flows. Packet size of flows to derive bandwidth / good-put statistics.

53 IPv6 Traffic Matrix

54 In-Band OAM for IPv6: Leveraging Proof-of-work Information

55 Service Chain Integrity Validation: Approach Add meta-data (ioam6 header) to all packets that traverse a service chain The added meta-data allows a verifying node (egress node) to check whether a packet traversed the service chain correctly or not Controller Security mechanisms are used on the meta-data to protect against incorrect or misuse (i.e. configuration mistakes, people playing tricks with routing, capturing, spoofing and replaying packets). verifier The meta-data is secured through the use of keys. Service functions retrieve the keys from a controller over a secure channel.

56 Service Chain Integrity Validation Approach #1 : Single shared secret General approach when no hardware assisted crypto available Approach #2 : Multiple secrets Approach when hardware assisted crypto is available

57 Service Chain Integrity Validation: Concept ( secret ) Controller ( shares of the secret ) Verifier

58 Approach #1 : Polynomials 101 Min 2 points Min 3 points Min 4 points General : It takes k+1 points to define a polynomial of degree k.

59 Approach #1: Idea Outline : Each service could be given a point on the curve. When the packet travels through each service it collects these points A verifier can reconstruct the curve using the collected points If there are k+1 services and k+1 points chosen, then the verifier can construct k degree polynomial and verify. The polynomial cannot be constructed if a few points are missed. Any lesser points means few services are missed! Concern: Operationally complex to configure and recycle so many curves and their respective points for each service function

60 Idea Concept Secret : (3,46) (1,16) (2,28) S1 S2 S3 Verifier

61 Approach # 1 : Complete Solution The idea is broadly to use two polynomials: 1. POLY-1 secret, constant. Each service gets a point on POLY-1 at set up time and kept secret 2. POLY-2 public, random and per packet. Each service generates a point on POLY-2 each time a packet crosses it. Each service function then calculates a (Point on POLY-1 + Point on POLY-2) to get a (Point on POLY-3) and passes it to verifier by adding it to each packet. The verifier constructs POLY-3 from the points given by all the services and cross checks whether POLY-3 = POLY-1 + POLY-2. Only the verifier knows POLY-1

62 Approach # 1 : Attack Model An attacker by passing a few services, will miss adding a respective point on POLY-1 to corresponding point on POLY-2, thus the verifier cannot construct POLY-3 for cross verification An attacker watching values, doing differential analysis across service functions (i.e. as the packets entering and leaving), cannot construct a point on POLY-1 as the operations are done in modulo prime. Doing differential analysis across packets could be mitigated with POLY-2 being be random Replay attacks could be avoided by carefully choosing POLY-2. It could be a timestamp concatenated with a random string. The proofs of correctness and security are based on Shamir s Secret Sharing Scheme.

63 Approach # 1 : Single Shared Secret Summary A single secret is associated with a particular service chain. Shares of the single secret are distributed from the controller to the service functions. Service functions use their share to update a cumulative value in the meta-data. Only a verifying node has access to the complete secret that it can use to validate the correctness of the received metadata. Notes The polynomial is the secret. Each point of the polynomial is called share of the secret. This is as per Shamir s Secret Sharing Scheme. All our proofs of correctness and security are followed by it.

64 Approach # 2 : Multiple Secrets Idea A service is described by a set of secrets, where each secret is associated with a service function. Service functions encrypt portions of the meta-data as part of their packet processing. Only the verifying node has access to all secrets. The verifying nodes re-encrypts the meta-data to validate whether the packet correctly traversed the service chain. Notes To be used only when hard ware assisted encryption is available. i.e. AES-NI instructions or equivalent. Otherwise this could be very costly operation to verify at line speed. S1 S2 Service-Secrets are nested like layers of an onion S3

65 Approach # 2 : Multiple Secrets Each packet is inserted with two additional fields RND (rand number) and SEQ (could be sequence or time stamp). An additional field VERIFY is initialized to NULL initially. Each time a packet passes through each service, then VERIFY = Enc(SEQ,K1) is XOR'ed with RND (as in AES-CTR mode). When the packet passed through the second service, then VERIFY = VERIFY XOR Enc(SEQ,k2). This is done in such cumulative XOR until service n, i.e. VERIFY = VERIFY XOR Enc(SEQ,kn). Since the verifier knows all the keys, it could do the same as above (NOT Decryption), i.e. VERIFY XOR Enc(SEQ, k1) XOR Enc(SEQ, k2)...xor Enc (SEQ, kn). The above would result in RND only when all the services give their respective encryption of SEQ else the packet could be flagged.

66 Approach # 2 : Multiple Secrets Pros Standard encryption techniques supported by hardware could be used Verification is trivial Cons Very expensive in case hardware support is not present

67 ioam6 Extension Header: Service Chain Verification Random Random (contd) Cumulative Cumulative (contd) End to end scope Hop-by-Hop information processing Values Random Unique random number (e.g. Timestamp or combination of Timestamp and Sequence number) Cumulative (algorithm dependent)

68 Service Chain Verification In Policy In Policy Out of policy Out of policy

69 In-Band OAM for IPv6: Leveraging Generic Meta-Data

70 User-Defined OAM Information hop_limit node_id ingress_if_id egress_if_id timestamp app_data Generic, user-defined application data inserted at selected hops into the ioam6 header Semantics of the data are user-defined

71 Example: Geo-Location added as App-Data Scenario Mobile IoT-Network Objective Visualize movement of devices Identify areas with high loss and/or delay probability Approach Insert geo-location information (e.g. GPS derived) into the appdata field of the ioam6 when packets are forwarded

72

73

74

75 Focus on a specific time

76 Identify those packets transfers which took longer than 20ms

77 In-Band OAM for IPv6: Status and Summary

78 Status: Proof Of Concept Available Software Dataplane: IOSv/VIRL, ISR, Linux Hardware Dataplane: Doppler ASIC Check out the demo on dcloud.cisco.com Service Provider category

79 Summary: In-Band OAM for IPv6 Enhanced visibility for all your traffic: New sources of data for SDN applications Network provided telemetry data gathered and added to live data Complement out-of-band OAM tools like ping and traceroute Enhance service chaining Record the packet s trip in an IPv6 extension header Record path and node (i/f, time, app-data) specific data hop-by-hop and end to end Export telemetry data via Netflow/IPFIX to Controller/Apps Implementation without forwarding performance degradation More Info? See demos at DevNet Zone and on dcloud.cisco.com Simplify Operations Easy ECMP Debugging Optimize Planning Easily derive traffic matrix Enhance Visibility Network-Delay Trends Enhance SLAs Service-Chain Validation

80 Participate in the My Favorite Speaker Contest Promote Your Favorite Speaker and You Could Be a Winner Promote your favorite speaker through Twitter and you could win $200 of Cisco Press products (@CiscoPress) Send a tweet and include Your favorite speaker s Twitter Two hashtags: #CLUS #MyFavoriteSpeaker You can submit an entry for more than one of your favorite speakers Don t forget to View the official rules at

81 Complete Your Online Session Evaluation Give us your feedback to be entered into a Daily Survey Drawing. A daily winner will receive a $750 Amazon gift card. Complete your session surveys though the Cisco Live mobile app or your computer on Cisco Live Connect. Don t forget: Cisco Live sessions will be available for viewing on-demand after the event at CiscoLive.com/Online

82 Continue Your Education Demos in the Cisco campus Walk-in Self-Paced Labs Table Topics Meet the Engineer 1:1 meetings Related sessions

83 Thank you

84