1 / 11

Handling MPLS-TP OAM Packets Targeted at Internal MIPs

Handling MPLS-TP OAM Packets Targeted at Internal MIPs. draft-farrel-mpls-tp-mip-mep-map-04 H. Endo , A. Farrel, Y. Koike, M. Paul, R. Winter. History. OAM framework specifies per-interface MIPs (two or more MIPs on each side of the forwarding engine)

barbra
Download Presentation

Handling MPLS-TP OAM Packets Targeted at Internal MIPs

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Handling MPLS-TP OAM Packets Targeted at Internal MIPs draft-farrel-mpls-tp-mip-mep-map-04 H. Endo , A. Farrel, Y. Koike, M. Paul, R. Winter

  2. History • OAM framework specifies per-interface MIPs (two or more MIPs on each side of the forwarding engine) • Does not specify how OAM packets destined to per-interface MIPs are handled • Many possible options...needs to be specified for implementors

  3. More history • Changes since -03 version • Removed the use of ACH TLVs based on feedback received • Removed the use of a reserved label based on feedback received • Described (two) new way(s) of addressing per interface MIPs • Merged with draft-koike-ietf-mpls-tp-oam-maintenance-points-01 • Appendix with ohter alternatives

  4. Requirements • Forwarding of OAM packets exactly as data packets without mis-ordering. • Delivery of OAM messages to the correct MPLS-TP node. • Direction of OAM instructions to the correct MIP within an MPLS-TP node (arrival at the wrong MIP should be handled). • Packet inspection at the incoming and outgoing interfaces must be minimized.

  5. Option 1 - Reserved bit • No semantic overlap with anything that exists • Still enough bits left (8 bits) • Potentially safe (must be ignored by legacy) • Hardware-friendly • Update to RFC 5586 and 4385, then works for both PWs and LSPs

  6. 0: ingress 1: egress 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LSP Label | TC |S| TTL | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | GAL | TC |S| TTL | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 0 1|Version| Reserved | Channel Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ACH TLV Header (if present) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ~ ~ Zero or more ACH TLVs ~ ~ (if present) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ~ ~ G-ACh Message ~ ~ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

  7. Option 2 – ID-based • Use existing ID information in the OAM messages • Leave it to the node implementation to deliver it • No „on-the-wire“ packet format changes required • Slightly more complex processing compared to option 1

  8. ID TLV 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LSP Label | TC |S| TTL | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | GAL | TC |S| TTL | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 0 1|Version| Reserved | Channel Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ACH TLV Header (if present) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ~ ~ Zero or more ACH TLVs ~ ~ (if present) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ~ ~ G-ACh Message ~ ~ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

  9. Option 2 and current solutions • draft-on-demand-cv-05 already specifies Ingress/Egress IF_Num • Address/ID TLVs • Not a fixed location (within and across solutions) therefore a SW solution is needed • Need to make sure this solution is satisfying all of the requirements

  10. Draft-on-demand-cv-05DSMAP/DDMAP address TLV 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MTU | Address Type | DS Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Ingress IF_Num (4 octets) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Egress IF_Num (4 octets) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Multipath Type| Depth Limit | Multipath Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

  11. Next steps • Come to a conclusion on which option to pick • Feedback please • Ensure this is safe in all conceivable cases (i.e. no OAM packet leakage) • WG adoption would be good • Even if it‘s just to get this requirement into the back of people‘s heads • would be standards track...or alternatively move the text into another document

More Related