The MPLS WG Archive

["tom worster" <tom@ennovatenetworks.com>]

From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of Riad
Hartani
> 
> A couple of questions regarding the MPLS-in-IP draft below:
> 
> 1) IP-in-IP encapsulation clearly describes how to set/handle 
> the outer IP
> header fields, such as TOS, Id/Flag/Fragment fields, TTL and 
> others. In this
> type of encapsulation, setting these fields is directly 
> related to how they
> are set within the inner IP header (eg: TOS is simply copied 
> from inner IP
> header). 
> 
> What are the procedures if the encapsulated packet is now an 
> MPLS packet
> rather than an IP packet ? Clear procedures (even if they are 
> trivial) would
> make the draft more clear (specially if the MPLS packet/label 
> is QoS aware).

that's an interesting question. i think it's hard to provide 
a specification like ip-in-ip since the correct handling of
the encapsulating ip header depends on whet you have inside
the mpls message. there might be a different behaviour, for 
example, when encapsulating an ipv4 packet from a vpn and
when carrying a compressed rtp packet. by not specifying such 
things we leave it open to the needs of the application. in
the case of ip-in-ip the procedures _can_ be specified since
the encapsulated packet is known to be ip. do you have any
specific examples?

as far as qos goes, we mentioned in the usage considerations
that diff-serv or rsvp/int-serv may be used. here again, if, 
how, and when to use these depends on the application. for
example, if the mpls-in-ip tunnel terminates directly on 
media gateways then one may have explicit qos requirements 
in terms of the voip application. in this case i don't see
that the mpls-in-ip spec should mention the qos mapping down
to network layer beyond that such a mapping may be used 
(which is what we already have).


> 2) In section 4, I suspect that security consideration inherent to IP
> encapsulation schemes will also apply in this case. So, additional
> precautions are needed when compared to the LSR/LER case.

this is true. perhaps i didn't mention it because it seemed
obvious to me.


> 3) Reading the abstract, one may think that extending a 
> Voice_over_IP over
> MPLS tunnel to a non MPLS-core by adding an IP encapsulation 
> is one of the
> motivations for this work. Well, I fail to see why. The 
> amount of overhead
> given the small voice packet size would be too large using 
> these successive
> encapsulation schemes. Is this really one of the motivations ?

yes. the compression of voip headers using mpls means that voip/
mpls/ip can be more efficient than voip. see for example thomas
theimer's draft. 

c u
tom


______________________________________________________________________
tom worster, ennovate networks, 60 codman hill rd, boxborough ma 01719
tel: +1 978 206 0490   fax: +1 978 263 1090   tom@ennovatenetworks.com