Re: [mpls] An approach to MNA PSD

["Rakesh Gandhi (rgandhi)" <[e-mail]>]

Hi Stewart,

Thanks for summarizing the proposal.

FYI:

This encoding in your email was defined for IOAM in [1] , including adding Length in Reserved field and IOAM ACH type, before switching to use the encoding from [draft-song-mpls-extension-header] in later version of the draft.

[1] https://datatracker.ietf.org/doc/draft-gandhi-mpls-ioam/05/


Thanks,
Rakesh


From: mpls <[e-mail]> on behalf of Stewart Bryant <[e-mail]>
Date: Thursday, February 23, 2023 at 11:23 AM
To: mpls <[e-mail]>
Subject: [mpls] An approach to MNA PSD

I am not sure if anyone has made this proposal, but I will make it in this email so that if there is no IPR on it, it would be difficult to claim additional IPR.

This is based on RFC 8169 which does had a RAND IPR disclosure but is a product of this WG,

RFC 8169 teaches that it is possible to have a first nibble 0001 GACH after the stack carrying a type of ancillary data  used to assist in the processing of time sensitive payloads. Some of those payloads requiring assistance are IP based. Of course we do not have to confine ourselves to time sensitive payloads in the MNA project. We could carry both time sensitive and time insensitive payloads.

The trigger for action on the GACH is an MPLS label in the labels stack and can be triggered by an on path router. Actioning GACH channels at an egress PE is well known.

If follows therefore that there is precedence for the MNA project to carry its PSD in a GACH with a first nibble of 0001 and for this to be accessed by on-path routers and to be actioned at speed in the egress PE.

So we could simply use a GACH with first nibble = 0001 and one or more channel type(s) allocated for this purpose. (For the IPR lawyers 00001 is preferable but any other first nibble value could be used as could any GACH structure other than the documented preferred structure).

We have hardly used any of the 64K channel types so we have plenty of space to allocate other types.

The design of the internals of the channel is a matter for the channel payload designer and the design would be obvious to any engineer ordinarily skilled in the art.

So we have three problems, firstly how would we skip over an ACH of unknown type. This is readily achieved by allocating up to 8 of the reserved bits to the purpose of carrying the length of the information carried in the channel. The exact number could be a fundamental parameter of the design, or a parameter fundamentally associate with a set of channel types. Equally the length could be carried in a well known place in the channel payload for a set of channel types.  For IPR coverage we could also use a different version number an a different GACH structure, or reallocate the whole of the GACH 32 bits in some other way.

There would be some merit in allocating a set of ACH types to this purpose allowing some to always present parameters  sited at well known locations within the channel structure.

The length would preferably be in octets but could be in other units such as two or four octets if that was preferred.

The second problem is how to carry more than one unit of PSD. That is achievable by first pushing the structure described above including its payload and then pushing one of more similar constructs.

If the payload was IP this could immediately follow the end of the last GACH + channel, or it could be carried as described in RFC 8169

That it was IP could thus be a property of the label stack or a property of the ACH mechanism described here.

If the ultimate payload was PW or similar, then the last of the PST GACH+channel pairs would be followed by a Control Word (CW) followed by the PW payload.

The type of PW or other non-IP payload may be a property of the label stack (as it is today) or could be readily encoded using the mechanisms previously described here.

I will look to write a very short draft with collegues if there is interest in this approach.

Best regards

Stewart









_______________________________________________
mpls mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/mpls