George Swallow Martin Vigoureux Rahul Aggerwal July 30, 2008 Assignment of the Generic Associated Channel Header Label (GAL) draft-vigoureux-mpls-tp-gal-00 George Swallow Martin Vigoureux Rahul Aggerwal July 30, 2008

Items to cover Segment OAM MEP to MEP MEP to MIP Stack operations TTL of GAL Applicability to MPLS

MPLS-TP Major Solution Constructs MPLS-TP alert label (TAL) Allows OAM packets to be directed to an intermediated node on a LSP/PWE Via label stacking or proper TTL setting Define a new reserved label (13 is suggested): Label 14 cannot be reused at this point Generic Associated Channel (GE ACH) supports full FCAPS functionality Use of PWE-3 Associated Channel to carry OAM packets GE ACH are codepoints from PWE ACH space but, not necessarily, for PWE purposes GE ACH would be present for OAM of all LSPs .

LSP monitoring and alarming Generic Alert Label and Generic Associated Channel Proposal MAC Header L1 L2 GAL/BoS Generic ACH Channel payload 0001 | Ver | Resv | Channel Type Assign a Transport Alert Label as a Label For yoU (LFU) from reserved label space: Label 13 has been proposed because, Label 14 has been allocated to Y.1711 Y.1711 arch fits within “ACH” architecture Bottom of Stack is always set on LFU in the transport profile Define a Generic Associated Channel function Similar to the PWE-3 Associated Channel First nibble is 0001; Channel Type field the same (but more values) Generic Associated Channel is always under a Generic Exception Label if endpoint (MEP) Generalised Associated Channel defines what packet function using “channel type” field Examples : What OAM function is carried, DCC, etc .

GAL Functions Serves as a protcol/format identifier to identify the MPLS payload as containing an Generic Associated Channel header The G-ACH in turn defines the specific contents Note that this defines a means for having an Associated Channel for LSPs where the FEC does not define one, e.g. a VPN route Serves to differentiate packets allowing them to be directed to the appropriate entity for processing At MEP, GAL causes exception handling of OAM packet At MIP, it is a combination of TTL of label above, plus GAL (GAL does not require peeking down the label stack)

Placement in Label Stack Always appears directly below the label for the LSP being monitored For the MPLS-TP null labels are not permitted This draft however, does not rule out use of the GAL in connection with a implicit or explicit null label Clearly not all OAM functions will work identically in this case

Placement in Label Stack (2) Note that more labels may be pushed onto the stack above the label of the LSP being monitored However the GAL only has meaning when the label of the LSP being monitored is at the top-of-stack

Placement in Label Stack (3) For the MPLS-TP the GAL always appears at EOS In general, however, this need not be the case - particularly where the intervening labels may influence the choice of ECMP Case in point - load balancing (aka entropy) labels

Canonical Format at a MIP or MEP 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 | CoS |S| TTL | | GAL | CoS |S| TTL | | Generic-ACH | | . . MPLS-TP OAM packet . . | Note: at MIP TTL of LSP Label is 1, at MEP any value

Nested T-MPLS Tunnels & OAM Carrier 1 Region 1 Region 2 PE P PE PE P PE INNI Carrier 1 LSP OAM segment MEP MIP MIP MEP MD Level 2 carrier 1 region 1 LSP OAM segment carrier 1 region 2 LSP OAM segment MEP MIP MEP MEP MIP MEP MD Level 1 Next Slide focus on MD Levels 1 & 2

Carrier 1 example MEPs/MIPs relationships MEL x: Carrier 1 Carrier 1 LSP segment OAM Sk So Pushing a new label at the MEP So starts a server layer trail that is terminated when the label is removed at the MEP Sk MIP[1] verifies MEPx_So connectivity to MEPy_Sk MIP[2] verifies MEPx_So connectivity to MEPz_So MIP [1] MIP [2] MEL y: Carrier 1, Region 1 MEL z: Carrier 1,Region 2 region 1 OAM region 2 OAM Sk So Sk So MEP MIP Trail A MIP must support monitoring on the ingress port (logically before the label swap) An implementation may optionally support a second MIP to monitor the egress port How will this MIP be addressed

Segment OAM Segment OAM is sent simply as GAL followed by the ACH Note that if we wish to use GAL with implicit null label, care will need to be taken to clearly deliniate that case from any defined Segment OAM

TTL of GAL Label Stack Entry This draft simply says TTL should be set to 1 When things are working properly (ignoring the cases of Segment OAM and Implicit Null) GAL TTL is never processed. Further GAL is always directed to an OAM process (not switched out of a box) Since GAL is a reserved label, a node that does not understand GAL will drop it

Forwarding and OAM: LSPs / PW OAM and Label Stacks

MEP to MIP OAM: TTL Processing for PWs and LSPs In order to maintain individual levels of OAM and path detection Use short pipe model per label level TTL is not copied up the stack on a push TTL is not copied down the stack on a pop TTL is decremented on each swap and pop action Traceroute for a level can be used to trap packets at each node that processes the label for that level in the label stack

Multi-Segment PW TTL Processing LSP PW A B C D E T-PE T-PE S-PE LSP LSP PW Label stack TTLs used on the wire TTL=k TTL=k-1 TTL=n TTL=n-1 TTL=j TTL=j TTL=j-1 TTL=j-1 A-B B-C C-D D- …

Multi-Segment PW TTL Processing LSP PW A B C D LSP LSP PW Label stack TTLs used on the wire TTL=k TTL=n TTL=n-1 TTL=j TTL=j-1 TTL=j-2 TTL=j-2 A-B B-C C-D D- …

Observation Indication of ACH can be done in FEC GAL is absolutely needed for PHP GAL is absolutely needed when FEC is already defined without GAL Definition of an MPLS-TP FEC could be defined with an ACH

Next Steps Technical content (near) complete Some text clean up needed Author believe far enough along to become a WG doc