All, Is the idea of using data plane to carry complete metadata is "the way" or "a way" of approaching the problem ? Has this been already discussed ?
I would rather consider to carry metadata in control plane and only attach a reference_id (and only when it is needed) to the data plane. Rgs, R. On Fri, Jul 18, 2014 at 3:58 AM, Xuxiaohu <[email protected]> wrote: > 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 > > _______________________________________________ > spring mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/spring >
_______________________________________________ spring mailing list [email protected] https://www.ietf.org/mailman/listinfo/spring
