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

From: "Andrew G. Malis" <[email-masked]>
Date: Mon, 07 Apr 2003 16:45:59 -0400

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

---

From: Sasha Vainshtein <[email-masked]>
Date: Tue, 8 Apr 2003 13:02:59 +0200

Andy and all,

I think you have given a very good analysis of the existing 
options. And I agree with you that using value '1000' (= 8)
in the first nibble of the RTP header (my original
preference) is a non-starter.

However, I disagree with your preference and think that 
Option 2 (an explicit MPLS PID word preceding the RTP header 
followed by the CW) is preferable to Option 3 (placing the 
potentially unused EBM before the CW); below I'll try to 
explain why.

1. As you have noticed, this option is "architecturally pure".
   IMO, this minimizes the risk of potential future problems

2. Please consider the case when the transport network is IP, and not
   MPLS. (The demultiplexing method is not important - it may be
   L2TPv3, MPLS-in-IP, MPLS-in-GRE or something else). In this case:
   a) There is no need at all in the MPLS PID
   b) There is a definite added value in using the same encapsulations
      for IP and MPLS transports
   c) There is a definite added value in preserving the traditional
      position of the RTP header relative to IP transport

3. IMO, Option 3 (your preference) does not provide a solution 
   for the case of Fractional VC4 (see Section 8.2.3.2 and 
   Figure 16 in draft-ieft-pwe3-sonet-01.txt).

I also think that estimates of BW effectiveness of 
Option 3 vs. Option 2 must take into account that, BW-wise, 
Fractional STS-1 and Fractional VC4 methods only make sense 
when you carry a substantial number of (concatenated) VTs 
between the given pair of endpoints. This is due to the 
fact that, with an individual VT, you MAY limit yourself 
to one packet every 500 uS, while with fractional STS-1 or
Fractional VC-4 you MUST generate at least one packet every 
125 uS and, in addition to that, must one additional byte 
(the TU pointer) per VT per 125 uS. So adding the MPLS PID
will simply change the break-even condition.

With best regards,
                                   Sasha Vainshtein
email:     [email-masked] <mailto:[email-masked]> 
tel:       +972-3-7659993 (office)
           +972-8-9254948 (res.)
           +972-58-674833 (cell.)

> -----Original Message-----
> From: Andrew G. Malis [mailto:[email-masked]]
> Sent: Monday, April 07, 2003 10:46 PM
> To: [email-masked]
> Cc: Andy Malis
> Subject: [PWE3] SONET/SDH header issues and proposed resolution (long)
> 
> 
> _______________________________________________
> pwe3 mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/pwe3
>

---

From: "Andrew G. Malis" <[email-masked]>
Date: Tue, 08 Apr 2003 06:33:41 -0400

Sasha,

Thanks for your reply.  Comments inline ....

>    IMO, this minimizes the risk of potential future problems

With all due respect, "potential future problems" is vague at best and FUD 
at worst.  If there's an actual problem to address, that's something else 
entirely.

>       position of the RTP header relative to IP transport

Note that section 4.5 in the SONET draft (L2TP) is for future study, and 
for good reason.  There has been zero interest in running SONET/SDH over 
anything but MPLS.  Certainly those of us that are implementing this (at 
least those of which I am aware) are only doing MPLS implementations.  I 
would rather optimize for the common case.

>    Figure 16 in draft-ieft-pwe3-sonet-01.txt).

It does handle it - that's the use of the "E" bit in the header - bit 0 in 
the second word.  But you're right in that we'll be unable to use the first 
word for this one case.  So in this case, the header will be:

  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|                         Reserved                      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1|R|D|N|P| Structure Pointer[0:12] |  Sequence Number[0:13]    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1|0|         Equipped Bit Mask #1 (EBM) [0:29] TUG-3#1         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1|0|         Equipped Bit Mask #2 (EBM) [0:29] TUG-3#2         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|E|0|         Equipped Bit Mask #3 (EBM) [0:29] TUG-3#3         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

>will simply change the break-even condition.

Actually, I think that helps make the case that you want to be as 
BW-efficient as possible in general.  We make out better in almost all 
cases with my proposal except for VC4, and in VC4 we break even with the 
MPLS protocol identifier proposal.

Cheers,
Andy

---------

---

From: Sasha Vainshtein <[email-masked]>
Date: Tue, 8 Apr 2003 15:36:19 +0200

Andy,
Please see some comments inline.

With best regards,
                                   Sasha Vainshtein

> Sent: Tuesday, April 08, 2003 12:34 PM
> To: Sasha Vainshtein
> Cc: 'Andrew G. Malis'; [email-masked]
> Subject: RE: [PWE3] SONET/SDH header issues and proposed 
> resolution (long)
> 
> 
> Sasha,
> 
... snipped ...
> Note that section 4.5 in the SONET draft (L2TP) is for future 
What about Section 4.4.1 and Figure 4 in the SONET draft? 
Are you going to limit the draft to MPLS-only?
And if not, then what do you propose?
> would rather optimize for the common case.
Does this include SONET-VT and Fractional STS-1/VC4? 
In other words, do you mean that there is zero interest 
in carrying just one or two VT-1.5s or VC-2s over an IP core?
And does this include inter-AS (with MPLS-in-IP) cases as well?
> word for this one case.  So in this case, the header will be:
Why not the MPLS PID as defined by Stewart? And why such a difference
between the case of Fractional VC4 vs. Fractional STS-1? (In one case
the flags, the structure pointer and the sequence number follow
the EBM, in the other case they precede it)?
In other words, why three different solutions instead of
one generic?
... snipped ...
> MPLS protocol identifier proposal.
I would say that you only do better for Fractional STS-1.
For all the rest of the cases your proposal gives exactly
the same BW efficiency as Option 2 (add 32 bits per packet).

---

From: "Ron Cohen" <[email-masked]>
Date: Tue, 8 Apr 2003 15:52:01 +0200

Andy,

I agree with Sasha. The MPLS PID is the only option that is relevant out
of the options you have listed.

I can just repeat what Sasha said, with the following remarks:

1. There are implementations that run SONET/SDH CEP over IP. There are
providers that do not run MPLS on their core and are interested in this
solution.

2. We need consistent fractional STS-1 and VC-4 encapsulations. We can
not reverse the encapsulation just for fractional STS-1, and have it
different for VC-4. 

3. I think that it should be a mistake to reverse the order of RTP
compared to the CEP header. It should be consistent in running any TDM
encapsulation on top of IP or MPLS. The CEP header should reside between
the RTP header and the SONET/SDH payload.

4. I think that we should not restrict RTP to run without X or P bits
set (here I disagree with Sasha). If one needs to run RTP on top of
MPLS, over ECMP enabled network, it should add the MPLS PID.

5. The MPLS PID should be optional, and should be used only when the
network requires IP flow support. Hence, the CEP header would be 4 bytes
for VT or STS-1, only longer for fractional STS-1/VC-4. 

Ron

> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Andrew G. Malis
> >I think you have given a very good analysis of the existing options. 
> >And I agree with you that using value '1000' (= 8) in the 
> first nibble 
> >of the RTP header (my original
> followed 
> >by the CW) is preferable to Option 3 (placing the potentially unused 
> >EBM before the CW); below I'll try to explain why.
> >
> Fractional 
> >STS-1 and Fractional VC4 methods only make sense when you carry a 
> >substantial number of (concatenated) VTs between the given pair of 
> >endpoints. This is due to the fact that, with an individual 
> VT, you MAY 
> >limit yourself to one packet every 500 uS, while with 
> fractional STS-1 
> >or Fractional VC-4 you MUST generate at least one packet every
> > >  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
> > > To review, draft-ietf-pwe3-sonet-01.txt currently has the 
> following 
> > > packet
> > > structure:
> > >
> > > 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
> > > 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
> > > 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
> > > This would place George and Stewart's proposed MPLS payload 
> > > identifier immediately after the labels and before the RTP header:
> > >
> > > identifier is actually 28 bits of redundant information, since 
> > > signaling and/or provisioning have already been used to 
> identify the 
> > > PW contents.  So
> > > 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,
> > > 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
> > > 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
> > > 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
> > >

---

From: "tom k. johnson" <[email-masked]>
Date: Tue, 8 Apr 2003 09:26:33 -0400

Stewart/Andy

If I'm reading your text correctly, that would say that either option 2 or option 3 would be acceptable (?)

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

> 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:
> > 
> > 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).
> > 
> 64 bits, and 
> > has the following structure:
> > 
> > Basic format:
> > 
> >  0                   1                   2                   3
> > 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.
> > 
> > 
> identifier 
> > 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).
> > 
> > 
> > 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.
> > 
> > architecturally "pure" than alternative 2, since the RTP 
> header follows 
> > the CEP header rather than precedes it.  But that's OK with me!
> >

---

From: Sasha Vainshtein <[email-masked]>
Date: Tue, 8 Apr 2003 17:10:55 +0200

Stewart, Andy and all,
Please see inline.

With best regards,
                                   Sasha Vainshtein

... snipped ...
> 
> 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.
>
IMO Option 3 as presented in Andy's latest email cannot be
considered as ONE solution: it saves the bytes in one case
and grandfathers the existing work in some other ones.
... snipped to the end ...

---

From: "Andrew G. Malis" <[email-masked]>
Date: Mon, 14 Apr 2003 10:45:11 -0400

Stewart,

Are you all set on the enclosed text?

Thanks,
Andy

------- Begin of Forwarded Message -------
X-Sender: vivacenet\[email-masked] (Unverified)
X-Mailer: QUALCOMM Windows Eudora Version 5.2.1
Date: Thu, 10 Apr 2003 18:25:35 -0400
To: Mustapha Aissaoui <[email-masked]>
From: "Andrew G. Malis" <[email-masked]>
Subject: Re: [PWE3] SONET/SDH header issues and proposed resolution
   (long)
Cc: "Andrew G. Malis" <[email-masked]>, [email-masked],
    "[email-masked]" <[email-masked]>
X-OriginalArrivalTime: 10 Apr 2003 22:25:41.0208 (UTC) 
FILETIME=[1E931D80:01C2FFB0]
Sender: [email-masked]
X-BeenThere: [email-masked]
X-Mailman-Version: 2.0.12
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/pwe3>,
         <mailto:[email-masked]?subject=unsubscribe>
List-Id: Pseudo Wires Edge to Edge <pwe3.ietf.org>
List-Post: <mailto:[email-masked]>
List-Help: <mailto:[email-masked]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/pwe3>,
         <mailto:[email-masked]?subject=subscribe>

Mustapha,

Good comment.  Does this work:

    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 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

    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.

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

          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 13: MPLS Preferred Control Word

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

Cheers,
Andy

------

At 4/10/2003 06:10 PM -0400, Mustapha Aissaoui wrote:

>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.
>-----------

------- End of Forwarded Message -------