Subject: Re: SONET/SDH header issues and proposed resolution (long)

From: Stewart Bryant <[email-masked]>
Date: Tue, 08 Apr 2003 14:59:40 +0100

tom k. johnson wrote:
> Stewart/Andy
> 
> If I'm reading your text correctly, that would say that either option 2 or option 3 would be acceptable (?)
> 

Yes.

Clearly the purest approach is always to use the MPLS PID (opt 2), but
just as we found a way to grandfather the Martini and ITU encaps (and
save the four bytes), I am OK with the SONET team saving the bytes.

However we do have to get to ONE solution, i.e. to decide if it is more
important to grandfather the existing work, or save the bytes.

Stewart

> If so, then I agree with your proposal for updating the architecture doc.
> 
> Then (I assume) it's up to each service draft to come up with an implementation.  For SONET, I'm fine with either option 2 or option 3.
> 
> Thanks!
> 
> -Tom
> 
> 
> 
>>-----Original Message-----
>>From: Stewart Bryant [mailto:[email-masked]]
>>Sent: Tuesday, April 08, 2003 6:45 AM
>>To: Andrew G. Malis
>>Cc: [email-masked]
>>Subject: Re: [PWE3] SONET/SDH header issues and proposed resolution
>>(long)
>>
>>
>>Good summary Andy
>>
>>Given that we have surfaced the issue of MPLS payload type
>>discrimination we should probably run the issue to its natural
>>conclusion.
>>
>>However Option (3) has the right ECMP properties, the
>>byte efficiency properties you are looking for and is
>>consistent with the other CW's at the necessary level.
>>
>>If this becomes the chosen option I suggest modifying the
>>PW arch draft to say :
>>
>>Preferably use the "Martini" encapsulation.
>>
>>If there are technical reasons, i.e. the requirements of the
>>PW, or the need for compatibility with other standards
>>then keep the first nibble == 0 for ECMP reasons.
>>
>>If even this is not possible, or there is a need multiplex something
>>else over the mux label, then use the MPLS PID.
>>
>>Do I have consensus?
>>
>>Stewart
>>
>>Andrew G. Malis wrote:
>>
>>> From following the PWE3 WG list, there is a clear 
>>
>>consensus that PWs 
>>
>>>need to take ECMP into account be using the upper nibble as 
>>
>>a PID.  So 
>>
>>>there are a few issues that have to be discussed in order 
>>
>>to amend the 
>>
>>>SONET/SDH draft to conform.
>>>
>>>To review, draft-ietf-pwe3-sonet-01.txt currently has the following 
>>>packet structure:
>>>
>>>+-----------------------------------+
>>>|   PSN and Multiplexing Layer      |
>>>|             Headers               |
>>>+-----------------------------------+
>>>|           RTP Header              |
>>>|           (RFC1889)               |
>>>+-----------------------------------+
>>>|           CEP Header              |
>>>+-----------------------------------+
>>>|                                   |
>>>|                                   |
>>>|           SONET/SDH               |
>>>|            Fragment               |
>>>|                                   |
>>>|                                   |
>>>+-----------------------------------+
>>>
>>>The first issue is the RTP header, which currently 
>>
>>immediately follows 
>>
>>>the labels.  Note that the RTP header can commonly be 
>>
>>compressed out, 
>>
>>>but when it is used, its first nibble will always be '1000' 
>>
>>(version = 
>>
>>>2, P = 0, X = 0, as shown in figure 3 in 
>>
>>draft-ietf-pwe3-sonet-01.txt).
>>
>>>The placement of the RTP header prior to the CEP header 
>>
>>isn't written in 
>>
>>>stone, and has been debated on the PWE3 list in the last few days.
>>>
>>>The second issue is the CEP header, which is either 32 or 
>>
>>64 bits, and 
>>
>>>has the following structure:
>>>
>>>Basic format:
>>>
>>> 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
>>>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>>|0|R|D|N|P| Structure Pointer[0:12] |  Sequence Number[0:13]    |
>>>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>>
>>>Extended Fractional STS-1 format:
>>>
>>> 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
>>>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>>|1|R|D|N|P| Structure Pointer[0:12] |  Sequence Number[0:13]    |
>>>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>>|E|0|0|0|            Equipped Bit Mask (EBM) [0:27]             |
>>>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>>
>>>Neither of these formats conforms to the ECMP requirement.
>>>
>>>There are some alternatives that can be used to bring the above in 
>>>compliance with the ECMP requirement.
>>>
>>>
>>>1. Allocate the nibble '1000' to indicate RTP after the labels.
>>>
>>>As has already been noted, IP version 8 has already been 
>>
>>assigned by 
>>
>>>IANA to "The P Internet Protocol".  While this protocol was 
>>
>>never widely 
>>
>>>implemented (was it ever implemented?), I cannot predict with any 
>>>certainty how easy or hard it would be reassign this value. 
>>
>> I can also 
>>
>>>imagine arguments outside of the PWE3 WG that RTP should always be 
>>>preceded by IP and UDP, and should not immediately follow a 
>>
>>link layer 
>>
>>>(treating MPLS as the link layer in this case).  So this is 
>>
>>probably a 
>>
>>>nonstarter.
>>>
>>>
>>>2. Use an MPLS payload identifier.
>>>
>>>This would place George and Stewart's proposed MPLS payload 
>>
>>identifier 
>>
>>>immediately after the labels and before the RTP header:
>>>
>>>+-----------------------------------+
>>>|   PSN and Multiplexing Layer      |
>>>|             Headers               |
>>>+----+------------------------------+
>>>|0001|    protocol identifier       |
>>>+----+------------------------------+
>>>|           RTP Header              |
>>>|           (RFC1889)               |
>>>+-----------------------------------+
>>>|           CEP Header              |
>>>+-----------------------------------+
>>>|                                   |
>>>|                                   |
>>>|           SONET/SDH               |
>>>|            Fragment               |
>>>|                                   |
>>>|                                   |
>>>+-----------------------------------+
>>>
>>>The primary problem with this solution is efficiency.  The protocol 
>>>identifier is actually 28 bits of redundant information, 
>>
>>since signaling 
>>
>>>and/or provisioning have already been used to identify the 
>>
>>PW contents.  
>>
>>>So we're really only using 4 bits to say "this is not IPv4 
>>
>>or IPv6", and 
>>
>>>the other 28 bits are unnecessary.
>>>
>>>To really illustrate the efficiently problem, recall that 
>>
>>the CEP header 
>>
>>>is currently 4 or 8 octets in length.  In the common case 
>>
>>when RTP is 
>>
>>>unused, this would in effect always be adding 4 octets to the CEP 
>>>header, increasing it to 8 or 12 octets, with the 12-octet 
>>
>>header being 
>>
>>>used in the more BW-constrained situations, or where you're 
>>
>>creating 
>>
>>>more PWs (SONET VTs).
>>>
>>>
>>>3. Change the headers and the RTP location.
>>>
>>>In this proposal, we would change the packet structure to:
>>>
>>>+-----------------------------------+
>>>|   PSN and Multiplexing Layer      |
>>>|             Headers               |
>>>+-----------------------------------+
>>>|           CEP Header              |
>>>+-----------------------------------+
>>>|           RTP Header              |
>>>|           (RFC1889)               |
>>>+-----------------------------------+
>>>|                                   |
>>>|                                   |
>>>|           SONET/SDH               |
>>>|            Fragment               |
>>>|                                   |
>>>|                                   |
>>>+-----------------------------------+
>>>
>>>and the CEP header would become a constant 8 octets in all cases:
>>>
>>> 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
>>>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>>|0|0|0|0|            Equipped Bit Mask (EBM) [0:27]             |
>>>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>>|E|R|D|N|P| Structure Pointer[0:12] |  Sequence Number[0:13]    |
>>>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>>
>>>When VTs are not in use, the first word will always be all 
>>
>>zeros, and 
>>
>>>the header length is the same as in option 2.  But when VTs 
>>
>>are in use, 
>>
>>>the header length is 4 octets LESS than in option 2.
>>>
>>>This alternative does not require the allocation of any new 
>>
>>PIDs, since 
>>
>>>we're going to be using 0000 anyway.  And how do we know 
>>
>>that this is a 
>>
>>>SONET header and not the usual other PWE3 header?  The same 
>>
>>as always - 
>>
>>>though PW signaling and/or provisioning.
>>>
>>>The only possible downside to this alternative is that it is less 
>>>architecturally "pure" than alternative 2, since the RTP 
>>
>>header follows 
>>
>>>the CEP header rather than precedes it.  But that's OK with me!
>>>
>>>Personally, I prefer this alternative.  I would be 
>>
>>interested in hearing 
>>
>>>other opinions.
>>>
>>>Thanks for listening,
>>>Andy
>>>
>>>_______________________________________________
>>>pwe3 mailing list
>>>[email-masked]
>>>https://www1.ietf.org/mailman/listinfo/pwe3
>>>
>>>
>>
>>
>>_______________________________________________
>>pwe3 mailing list
>>[email-masked]
>>https://www1.ietf.org/mailman/listinfo/pwe3
>>
> 
> 
>

---

From: "Andrew G. Malis" <[email-masked]>
Date: Thu, 10 Apr 2003 14:46:18 -0400

Stewart,

The co-authors have put their heads together, as it were (and it wasn't all 
that painful, either :-) and agreed to go with option #2 (the 
architecturally pure approach, summarized below).  So that's how you can 
write it up in the architecture spec, and we'll update the SONET/SDH spec 
to match.

Cheers,
Andy

--------

At 4/8/2003 02:59 PM +0100, Stewart Bryant wrote:

Stewart

........

This would place George and Stewart's proposed MPLS payload identifier
immediately after the labels and before the RTP header:

---

From: Stewart Bryant <[email-masked]>
Date: Thu, 10 Apr 2003 21:22:24 +0100

Good News.

I think that the version of the 5.4.3 and 5.4.4 that I sent to
the list earlier today is consistent with this. If not please
let me know.

Stewart

Andrew G. Malis wrote:
> Stewart,
> 
> The co-authors have put their heads together, as it were (and it wasn't 
> all that painful, either :-) and agreed to go with option #2 (the 
> write it up in the architecture spec, and we'll update the SONET/SDH 
> spec to match.
> 
> Cheers,
> Andy
> 
> --------
>

---

From: "Andrew G. Malis" <[email-masked]>
Date: Thu, 10 Apr 2003 17:45:28 -0400

Stewart,

I would like to suggest some simplifications to the first part in your text:

    To allow accurate packet inspection in an MPLS PSN, and/or to operate
    correctly over MPLS PSNs that have deployed equal-cost multiple-path
    load-balancing, a PW packet MUST NOT alias an IP packet.  IP packets
    are carried in MPLS label stacks without any protocol identifier.
    Historic values of the IP version number [RFC791] [RFC1881] are
    therefore used to distinguish between IP and non-IP MPLS payloads.
    Thus,an MPLS payload with bits 0..3 = 4 is a priori an
    IPv4 packet and an MPLS payload with bits 0..3 = 6 is an IPv6 packet.

    To disambiguate the PW from an IP flow the PW MAY either employ
    the preferred PW control word shown in Figure 12 or an MPLS payload
    type identifier (see Section 5.4.4):

          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
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |0 0 0 0| Flags |FRG|  Length   | Sequence Number               |
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

         Figure 12: MPLS Preferred Control Word

    Note that not all PWE3 encapsulations over MPLS use this control word 
format.
    For example, the SONET/SDH encapsulation uses a different control word 
format.
    In the general case, if the MPLS payload does not begin with a control word
    as illustrated in Figure 12, then the payload MUST begin with an MPLS 
payload
    type identifier.  There is one exception to this requirement; if a service
    provider is not using ECMP, then the provider SHOULD be able to use
    provisioning to suppress the transmission of the MPLS payload type 
identifier.

    The meaning of the fields of the MPLS Preferred Control Word (Figure
    12) is as follows:

The rest of the text is the same.

Thanks,
Andy

-------

---

From: Mustapha Aissaoui <[email-masked]>
Date: Thu, 10 Apr 2003 18:10:39 -0400

Andy,
I would like to keep the original Figure 12 in Stewart's text as it
covers the case of the 1:1 and PDU ATM encapsulations. If a PW
encapsulation cannot comply to the Generic PW Control Word, then it
should use the MPLS Payload Identifier, which is the option the
SONET draft authors chose to make.

Regards,
Mustapha.
-----------

---

From: "Andrew G. Malis" <[email-masked]>
Date: Thu, 10 Apr 2003 18:25:35 -0400

Mustapha,

Good comment.  Does this work:

    To disambiguate the PW from an IP flow the PW MAY either employ
    the Generic PW Control Word shown in Figure 12 or an MPLS payload
    type identifier (see Section 5.4.4):

          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
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |0 0 0 0|          Specified by PW Encapsulation                |
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

         Figure 12: Generic PW Control Word

    A particular usage of the MPLS Generic Control Word is the MPLS Preferred
    Control Word, shown in Figure 13:

          0                   1                   2                   3

         Figure 13: MPLS Preferred Control Word

Cheers,
Andy

------

---

From: Mustapha Aissaoui <[email-masked]>
Date: Thu, 10 Apr 2003 18:33:33 -0400

Andy,
it looks good to me. Thanks.

Mustapha.
------------

---

From: Stewart Bryant <[email-masked]>
Date: Fri, 11 Apr 2003 07:40:43 +0100

Andy

This works fine for everything except the ATM modes. Hence the
generic/prefered text.

Stewart

Andrew G. Malis wrote:
>    For example, the SONET/SDH encapsulation uses a different control 
> word format.
>>> The co-authors have put their heads together, as it were (and it 
>>> wasn't all that painful, either :-) and agreed to go with option #2 
>>> (the architecturally pure approach, summarized below).  So that's how 
>>> you can write it up in the architecture spec, and we'll update the 
>>> SONET/SDH spec to match.
>>> Cheers,
>>> Andy
>>> --------

---

From: "Andrew G. Malis" <[email-masked]>
Date: Fri, 11 Apr 2003 05:42:55 -0400

Stewart,

Did you see my revised text after Mustapha made the same comment?

Cheers,
Andy

---------

At 4/11/2003 07:40 AM +0100, Stewart Bryant wrote:

>>>>architecturally pure approach, summarized below).  So that's how you 
>>>>can write it up in the architecture spec, and we'll update the 
>>>>SONET/SDH spec to match.
>>>>Cheers,
>>>>Andy
>>>>--------