The presence of metadata within an MPLS packet must be indicated in the encapsulation. I think that's the "why" you may want to know.
Best regards, Xiaohu > -----Original Message----- > From: [email protected] [mailto:[email protected]] > Sent: Friday, July 18, 2014 11:11 AM > To: Xuxiaohu; [email protected] > Cc: [email protected]; [email protected] > Subject: RE: How to carry metadata/context in an MPLS packet > > How? A better question is "why?" > > What has to be done in MPLS that cannot be done outside it? > > Lloyd Wood > http://about.me/lloydwood > ________________________________________ > From: mpls <[email protected]> on behalf of Xuxiaohu > <[email protected]> > Sent: Friday, 18 July 2014 11:58 AM > To: [email protected] > Cc: <[email protected]>; [email protected] > Subject: [mpls] How to carry metadata/context in an MPLS packet > > Hi all, > > I'm now considering how to carry metadata/context in an MPLS packet. I just > noticed that draft-guichard-mpls-metadata-00 > (http://tools.ietf.org/html/draft-guichard-mpls-metadata-00#page-6) proposes > a way to carry metadata/context in an MPLS packet (see below): > > "3. Metadata Channel Header Format > > The presence of metadata within an MPLS packet must be indicated in > the encapsulation. This document defines that the G-ACh Generic > Associated Channel Label (GAL) [RFC5586] with label value 13 is > utilized for this purpose. The GAL label provides a method to > identify that a packet contains an "Associated Channel Header (ACH)" > followed by a non-service payload. > > [RFC5586] identifies the G-ACh Generic Associated Channel by setting > the first nibble of the ACH that immediately follows the bottom label > in the stack if the GAL label is present, to 0001b. Further > [RFC5586] expects that the ACH not be used to carry user data > traffic. This document proposes an extension to allow the first > nibble of the ACH to be set to 0000b and, when following the GAL, be > interpreted using the semantics defined in > [I-D.guichard-metadata-header] to allow metadata to be carried > through the G-ACh channel." > > However, it seems that the special usage of the GAL as mentioned above still > conflicts with the following statement quoted from [RFC5586]: > > " The GAL MUST NOT appear in the label stack when transporting normal > user-plane packets. Furthermore, when present, the GAL MUST NOT > appear more than once in the label stack." > > I wonder whether the special usage of the GAL as proposed in the above draft > would result in any backward compatibility issue. In addition, I wonder > whether > it's worthwhile to reconsider the possibility of introducing a Protocol Type > (PT) > field immediately after the bottom of the MPLS label stack. With such PT > field, > any kind of future MPLS payload (e.g., metadata header or NSH) can be easily > identified. > > Best regards, > Xiaohu > > _______________________________________________ > mpls mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/mpls _______________________________________________ spring mailing list [email protected] https://www.ietf.org/mailman/listinfo/spring
