The MPLS WG Archive

Cell Relay Retreat>MPLS WG Archive>month:2003-Feb> msg00100



[Date Prev][Date Next][Thread Prev][Thread Next]  
  [Date Index][Thread Index][Author Index][Subject Index]

E2E VoIP over MPLS ('VoMPLS') Header Compression - End-to-EndMPLS

  • From: "GOODE, B (Bur), ALABS" <bgoode@att.com>
  • Date: Sun, 23 Feb 2003 13:15:34 -0500
  • Cc: "Ash, Gerald R (Jerry), ALABS" <gash@att.com>, "raymond zhang" <zhangr@info.net>, "MPLS@UU.net" <MPLS@UU.NET>, "George Swallow" <swallow@cisco.com>
  • Thread-Index: AcLbZUlSIAfT7zFlS8i13Kf6BvePaQAAK3Gw
  • Thread-Topic: E2E VoIP over MPLS ('VoMPLS') Header Compression - End-to-EndMPLS
  • X-MIME-Autoconverted: from quoted-printable to 8bit by cell.onecall.net id h1NIDhP04565

Loa, we started with a problem and a statement of requirements.  In the
beginning, we discussed the problem and the requirements with George
Swallow and Dave Oran 18 months ago.  At that time, there was no IETF
process for documenting the problem and the requirements.  We started
working on potential solutions months after we defined the problem and
requirements.  When we felt we had a couple of potential solutions, we
submitted them as IDs.  Three months after we submitted the drafts, and
17 months after the first problem statement and identification of the
requirements, you came along and demanded that we write a requirements
document.  So we wrote a requirements document, which we have just
submitted to the internet drafts editor.  

Loa, you should ask yourself, are you trying to be objective? 

Bur  

> -----Original Message-----
> From: Loa Andersson [mailto:loa@pi.se]
> Sent: Sunday, February 23, 2003 12:42 PM
> To: Jim Hand
> Cc: curtis@fictitious.org; Ash, Gerald R (Jerry), ALABS; 'raymond
> zhang'; 'MPLS@UU.net'; 'George Swallow'; 'Loa Andersson'; GOODE, B
> (Bur), ALABS; 'Dave Cooper'
> Subject: Re: E2E VoIP over MPLS ('VoMPLS') Header Compression -
> End-to-EndMPLS
> 
> 
> All,
> 
> it wouldn't be hard to make the point based on this discussion that I 
> tried to
> make when this discussion just started.
> 
> I seems like a good idea to split the docs into two
>  
> 1. problem and requirments
> 2. the solution
> 
> I can't really escape the impression that what is going on 
> here is that 
> one is
> looking into the solution to try to find out what the 
> requirments really 
> were.
> 
> /Loa
> 
> Jim Hand wrote:
> 
> >	Maybe we need to re-write 
> draft-ash-e2e-crtp-hdr-compress-00 to clarify.  I
> >will look into this.
> >
> >	This draft does require RSVP TE e2e over the MPLS part 
> of the network, but
> >it does not require that MPLS or RSVP TE be extended to 
> CE's.  And it does
> >not require that the original compressor and decompressor be 
> attached to
> >MPLS.
> >
> >	Also, it does require that routers other than MPLS "P" 
> routers have the
> >ability to support compression and decompression.   But that 
> does not mean
> >that these routers will have to *perform* compression and 
> decompression on
> >each compressed packet.  Routers that support compressed 
> packets on both
> >input links and output links should only have to perform a
> >decompression/compression cycle on a small fraction of the 
> total number of
> >packets.  Most compressed packets would be switched from 
> input to output
> >without performing decompression and compression.
> >
> >Thanks,
> >Jim
> >
> >  
> >
> >>draft-ash-e2e-vompls-hdr-compress-00 requires e2e rsvp/te 
> mpls for the
> >>above definition of e2e which I hope I don't have to repeat 
> with every
> >>email message.
> >>
> >>draft-ash-e2e-crtp-hdr-compress-00 requires either of two 
> conditions.
> >>1) e2e rsvp/te mpls (for the above definition of e2e), 2) 
> every router
> >>along the way knows how to do compression and decompression.
> >>
> >>Case #2 is the one that SP are saying is impractical because the PE
> >>CPU is overloaded with too many PPS.  Except for this 
> practical matter
> >>case #2 is every bit as good a solution for the CE-PE links 
> as rfc2508
> >>over PPP links (with most CE-PE being PPP).  Needless to say that
> >>makes case #2 completely absurd in the core (comp/decomp on oc192c
> >>interfaces).
> >>
> >>That brings us to draft-ash-e2e-vompls-hdr-compress-00 requires e2e
> >>rsvp/te mpls and draft-ash-e2e-crtp-hdr-compress-00 case 1 which
> >>requires e2e rsvp/te mpls plus requires every hop in the path to
> >>support comp/decomp making it even worse.
> >>
> >>Curtis
> >>
> >>
> >>    
> >>
> >>>>-----Original Message-----
> >>>>From: Curtis Villamizar [mailto:curtis@fictitious.org]
> >>>>Sent: Wednesday, February 19, 2003 11:25 AM
> >>>>To: Ash, Gerald R (Jerry), ALABS
> >>>>Cc: curtis@fictitious.org; raymond zhang; MPLS@UU.net;
> >>>>        
> >>>>
> >>George Swallow;
> >>    
> >>
> >>>>Loa Andersson; GOODE, B (Bur), ALABS; Hand, James C, ALABS;
> >>>>Dave Cooper
> >>>>Subject: Re: E2E VoIP over MPLS ('VoMPLS') Header Compression
> >>>>        
> >>>>
> >>>>Please correct me if I'm wrong but your drafts seem to
> >>>>        
> >>>>
> >>require end2end
> >>    
> >>
> >>>>MPLS where RTP/UDP/IP/MPLS normally requires just end2end
> >>>>        
> >>>>
> >>IP.  Since
> >>    
> >>
> >>>>you are providing new RSVP/TE objects the assumption seems to be
> >>>>RSVP/TE MPLS edge to edge.  If traffic engineering is done within
> >>>>regions as can be done with current RTP/UDP/IP/MPLS regardless of
> >>>>whether LDP is also used, that works fine and scales
> >>>>        
> >>>>
> >>extremely well.
> >>    
> >>
> >>>>E2E RSVP/TE MPLS all the way to each peice of VOIP gear
> >>>>        
> >>>>
> >>is unlikely to
> >>    
> >>
> >>>>scale well in a single provider and is almost certain to become a
> >>>>severe problem crossing SP boundaries.
> >>>>
> >>>>Curtis
> >>>>
> >>>>        
> >>>>
> >>>      
> >>>
> >
> >
> >
> >  
> >
> 
> 
>