Re: [mpls] How to indicate the existence of an explicit protocol field immediately after the MPLS label stack?

[Stewart Bryant <[e-mail]>]

Sasha is correct, and I seem to remember a PW system that did meet an 
Ethernet packet with IPv4 as the first nibble and made such a mistake.


You can only use the first nibble as a disambiguator for example to 
distinguish IPv4 and IPv6 if you have some supplementary information 
telling you that the packet can only be either type IPv4 or IPv6.


Stewart



On 13/10/2016 06:36, Alexander Vainshtein wrote:
>
> Xiaohu and all,
>
> I respectfully disagree with your statement "*/the first nibble of the 
> MPLS payload has actually been used as an implicit protocol identifier 
> for some payloads/*". In the case of PWs the CW (with this first 
> nibble) may be not present at all, but even when it is present, its 
> first nibble is only used for disambiguation of the PW packets (so 
> that they cannot be mistakenly treated as IPv4 or IPv6 packets by the 
> ECMP mechanisms).
>
>
> My 2c,
>
> Sasha
>
>
>
>
>
>
>
> ------------------------------------------------------------------------
> *From:* mpls <[e-mail]> on behalf of Xuxiaohu 
> <[e-mail]>
> *Sent:* Thursday, October 13, 2016 6:49 AM
> *To:* [e-mail]
> *Cc:* [e-mail]; [e-mail]
> *Subject:* [mpls] How to indicate the existence of an explicit 
> protocol field immediately after the MPLS label stack?
> Hi all,
>
> It's well-known that the MPLS label stack has no EXPLICIT protocol 
> identifier field to indicate the protocol type of the MPLS payload. 
> However, the first nibble of the MPLS payload has actually been used 
> as an implicit protocol identifier for some payloads, such as IPv4 
> (0100), IPv6(0110) and MPLS-BIER (0101, for more details, please see 
> https://tools.ietf.org/html/draft-ietf-bier-mpls-encapsulation-05#page-5). 
> Unfortunately, the first nibble space is not enough for the 
> sustainable development of new encapsulation headers which may happen 
> to be encapsulated with an MPLS header. Furthermore, the remaining 
> first nibble space available for payload indication is only 0111 due 
> to the NSH specification 
> (https://tools.ietf.org/html/draft-ietf-sfc-nsh-10#page-7) unless the 
> NSH is restricted from being transported directly over the MPLS 
> transport (in this case the NSH is sadly not transport independent 
> anymore).
>
> Hence, it's seem necessary for us to consider the approach of 
> inserting an EXPLICIT protocol identifier field within the MPLS packet 
> as early as possible. The following are two possible ways of inserting 
> an EXPLICIT protocol identifier field within the MPLS packet:
>
> One is to use an SPL (or even ESPL) as described 
> (https://tools.ietf.org/html/draft-xu-mpls-payload-protocol-identifier-01). 
> See the following figure:
>
>      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
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>      |                 PIL                   | EXP |1|      TTL      |
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>      |0 0 0 0|       Reserved          |        Protocol Type        |
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>      | Payload                          |
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
> Another is to set the first nibble of the 4-octet entry containing the 
> protocol field to a dedicated value (e.g., 1111), as shown in the 
> following figure. In this case, there is no need to insert additional 
> label (s) (i.e., SPL or ESPL) anymore. The logic of the latter 
> approach is that the first nibble of the MPLS payload has been 
> implicitly used as a protocol id (e.g., in the case where the payload 
> is IPv4 or IPv6 packet), and since the 4-bit (implicit) protocol id 
> field is not extensible, we introduce a longer (explicit) protocol id 
> field as per the approach of ESPL.
>        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
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>        |             Bottom Label              | EXP |1|      TTL      |
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>        |0 1 1 1|       Reserved          | Protocol Type        |
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>        | Payload                          |
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
> IMHO, the benefits of introducing an explicit protocol id into the 
> MPLS packet include but not limited to: 1) provide a sustainable way 
> of indicating new MPLS payload types without any need of inserting one 
> additional label indicating the MPLS payloads (e.g., considering how 
> to transport NSH over MPLS networks); 2) there is no need any more for 
> each new encapsulation header to deal with the notorious first nibble 
> issue associated with MPLS individually. More specifically, there is 
> no need to intentionally avoid the first nibble of each new 
> encapsulation header from being 0100 (IPv4) or 0110 (IPv6).
>
> Any comments and suggestions are welcome.
>
> Best regards,
> Xiaohu
>
> _______________________________________________
> mpls mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mpls
> mpls Info Page - Internet Engineering Task Force 
> <https://www.ietf.org/mailman/listinfo/mpls>
> www.ietf.org
> For information about the MPLS working group, see 
> http://www.ietf.org/html.charters/mpls-charter.html. To see the 
> collection of prior postings to the list, visit ...
>
>
>
>
>
> _______________________________________________
> mpls mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mpls