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

From: Xuxiaohu <[email-masked]>
Date: Thu, 13 Oct 2016 03:49:14 +0000

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

---

From: Alexander Vainshtein <[email-masked]>
Date: Thu, 13 Oct 2016 05:36:02 +0000

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 <[email-masked]> on behalf of Xuxiaohu <[email-masked]>
Sent: Thursday, October 13, 2016 6:49 AM
To: [email-masked]
Cc: [email-masked]; [email-masked]
Subject: [mpls] How to indicate the existence of an explicit protocol field immediately after the MPLS label stack?

Hi all,

     0                   1                   2                   3

Best regards,
Xiaohu

_______________________________________________
mpls mailing list
[email-masked]
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 ...

---

From: Stewart Bryant <[email-masked]>
Date: Thu, 13 Oct 2016 13:53:41 +0100

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 <[email-masked]> on behalf of Xuxiaohu 
> <[email-masked]>
> *Sent:* Thursday, October 13, 2016 6:49 AM
> *To:* [email-masked]
> *Cc:* [email-masked]; [email-masked]
> *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
> 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
> 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).
>
> 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 ...
>
>
>
>
>