Subject: AW: PPP protocol type for MPLS packets ...

From: [email-masked]
Date: Wed, 16 May 2001 11:01:25 +0200

Hi Elwin,

even if protocol compression (the PFC option) is negotiated by LCP, you still can choose to
send your PPP frame using 16 bit protocol field. The PPP implementation
must be able to detect this.

regards,

Xiaoning

-----Ursprüngliche Nachricht-----
Von: Elwin Eliazer [mailto:[email-masked]]
Gesendet am: Dienstag, 15. Mai 2001 19:17
An: Eric Gray; Eric Rosen; George Swallow; Scott Bradner
Cc: [email-masked]; [email-masked]
Betreff: Re: PPP protocol type for MPLS packets ...

Hi Eric,

Thanks for your response.

But my question was not about the MPLSCP (control)
packets.... it is rather the payload MPLS packets.

Could you clarify if you are also referring the
same.

Thanks,
Elwin.

--- Eric Gray <[email-masked]> wrote:
> Elwin,
> 
>     Quoting from Standard 51 (PPP), section 6.5
> towards the bottom of
> page 48:
> 
> "The Protocol field is never compressed when sending
> any LCP packet.
>  This rule guarantees unambiguous recognition of LCP
> packets."
> 
>
====================================================================
> Eric/George/Scott,
> 
> On a related issue, I notice that - while RFC 3032
> lists the MPLSCP
> protocol number as 0x8281 - PPP-numbers, located at:
> 
>    
>
ftp://ftp.isi.edu/in-notes/iana/assignments/ppp-numbers
> 
> Shows this number assigned as follows -
> 
> "8281   Tag Switching - Unicast             
> [Davie]"
> 
> I can't recall any discussion about re-assigning
> this protocol number
> and I wonder - is possible at this point to make
> this happen (between
> B. Davie, Cisco and IANA)?
> 
> --
> Eric Gray
> 
> You wrote:
> 
> > Hi,
> >
> > Will it be a good practice to disable protocol
> > field compression (during LCP) as the PPP protocol
> > field value for MPLS unicast and multicast are
> > 0x0281 and 0x0283, as defined in RFC 3032,
> > section 4.3, that has the most significant
> > byte as non-zero?
> >
> > regards,
> > Elwin.
> >
> > =====
> > -------
> > Elwin Stelzer Eliazer
> > Corona Networks
> > San Jose, CA
> > 408-519-3832
> > -------
> >
> > __________________________________________________
> > Do You Yahoo!?
> > Yahoo! Auctions - buy the things you want at great
> prices
> > http://auctions.yahoo.com/
> 

=====
-------
Elwin Stelzer Eliazer
Corona Networks
San Jose, CA
408-519-3832
-------

__________________________________________________
Do You Yahoo!?
Yahoo! Auctions - buy the things you want at great prices
http://auctions.yahoo.com/

---

From: Eric Gray <[email-masked]>
Date: Wed, 16 May 2001 10:23:31 -0400

Xiaoning,

    The compression scheme relies on the fact that only odd
numbers are allocated.  The last byte of the protocol number
is known to have been received when a byte of the protocol
number field has been received with the LSB set.  Therefore,
most implementations might easily be able to recognize a PPP
protocol that is an arbitrary number of bytes long.  However,
PPP specification _requires_ that an implementation is able to
recognize a 16 bit protocol field, even when PFC is in use.

--
Eric Gray

---

From: Elwin Eliazer <[email-masked]>
Date: Wed, 16 May 2001 15:36:39 -0700 (PDT)

Thanks for all your clarifications.
The compression achieved in protocol field is
probably negligible, when considering the high speed
links (POS) the MPLS packet is likely to traverse
through.

thanks,
Elwin.

--- Eric Gray <[email-masked]> wrote:
> > even if protocol compression (the PFC option) is
> negotiated by LCP, you still can choose to

=====
-------
Elwin Stelzer Eliazer
Corona Networks
San Jose, CA
408-519-3832
-------