Subject: [RAM] be afraid...

From: Fred Baker <[email-masked]>
Date: Tue, 30 Jan 2007 15:32:15 -0800

Begin forwarded message:

> From: "Brett Thorson" <[email-masked]>
> Date: January 30, 2007 7:13:12 AM PST
> To: "'NAv6TF'" <[email-masked]>
> Subject: [nav6tf] IP Addressing Thoughts
> Reply-To: [email-masked]
>
> I received this e-mail from a gentleman in our government.  He was
> wondering if we had any thoughts on his IP Addressing methodology.   
> I'll
> be happy to collect answers and post them to our soon to be FAQ.  I  
> have
> included his name and e-mail at the bottom (with his permission) so  
> if you
> wanted to CC him in on this discussion, feel free to do so.
>
> My own comment: I think it is great to see government entities that  
> aren't
> under the OMB mandate to be looking into IPv6.  Finally, people who
> understand!!
>
> --Brett
>
> A little background may help - I work for the Administrative Office  
> of the
> United States Courts, the third branch of the federal government.   
> We have
> a large WAN with more than 600 endpoints that is based on IPv4.
> Recognizing that the future will be here before we realize,  
> planning for
> IPv6 has started even though as the third branch, we are not bound  
> by OMB
> mandates, or other executive branch dictates.
>
> One of the issues we are looking at is how best to use the large  
> address
> space that IPv6 will provide. The addresses used in the current  
> network
> are distributed geographically.  This was originally done as the first
> iteration of our WAN was a hub-and-spoke architecture.
>
> One thought that came to mind was to distribute IPv6 addresses  
> based on
> the class of/quality of service required.  VOIP would get one range of
> addresses, non real-time data another, etc... - sort of like a big  
> brother
> to MPLS. Routers could be connected to different WAN backbone
> architectures such as one port to a point-to-point low latency link  
> for
> voice, another port to a frame relay or similar slower less QoS/CoS  
> aware
> protocol for e-mail, etc..  Based on the network address the router  
> would
> place the data packet on the correct WAN network port. Different  
> length
> queues could be set up for each port to keep all traffic flowing  
> smoothly.
>
> Has any other organization given any thought to such an addressing  
> scheme?
>  Are there any problems that this would cause?
>
> It just seemed to make more sense from the wide area network  
> perspective
> than MPLS.  This scheme may also allow router resources such as CPU
> cycles, to be dedicated to particular types of traffic - maybe  
> there are
> different router architectures that would be better with forwarding  
> voice
> packets over UDP others forwarding non-real time data over TCP.
>
> Steven Eiserman
> Office of Information Technology/Infrastructure Management Division
> Administrative Office of the U.S. Courts
> [email-masked]
Begin forwarded message:

> From: "Davis, Terry L" <[email-masked]>
> Date: January 30, 2007 7:20:38 AM PST
> To: <[email-masked]>, "NAv6TF" <[email-masked]>
> Subject: RE: [nav6tf] IP Addressing Thoughts
>
> Brett
>
> I have several charts on the very addressing concept that he is
> suggesting.  I believe that type of addressing architecture will be
> critical to fully developing a QoS that will support needs like voice
> and real-time in the coming generation of Internet services.  It also
> fits very nicely with the way commercial aircraft are designed  
> already.
>
> Take care
> Terry
>
>> -----Original Message-----
>> From: Brett Thorson [mailto:[email-masked]]
>> Sent: Tuesday, January 30, 2007 7:13 AM
>> To: 'NAv6TF'
>> Subject: [nav6tf] IP Addressing Thoughts
>>
>> I received this e-mail from a gentleman in our government.  He was
>> wondering if we had any thoughts on his IP Addressing methodology.
> I'll
>> be happy to collect answers and post them to our soon to be FAQ.  I
> have
>> included his name and e-mail at the bottom (with his permission)  
>> so if
> you
>> wanted to CC him in on this discussion, feel free to do so.
>>
>> My own comment: I think it is great to see government entities that
> aren't
>> under the OMB mandate to be looking into IPv6.  Finally, people who
>> understand!!
>>
>> --Brett
>>
>> A little background may help - I work for the Administrative  
>> Office of
> the
>> United States Courts, the third branch of the federal government.  We
> have
>> a large WAN with more than 600 endpoints that is based on IPv4.
>> Recognizing that the future will be here before we realize, planning
> for
>> IPv6 has started even though as the third branch, we are not bound by
> OMB
>> mandates, or other executive branch dictates.
>>
>> One of the issues we are looking at is how best to use the large
> address
>> space that IPv6 will provide. The addresses used in the current
> network
>> are distributed geographically.  This was originally done as the  
>> first
>> iteration of our WAN was a hub-and-spoke architecture.
>>
>> One thought that came to mind was to distribute IPv6 addresses based
> on
>> the class of/quality of service required.  VOIP would get one  
>> range of
>> addresses, non real-time data another, etc... - sort of like a big
> brother
>> to MPLS. Routers could be connected to different WAN backbone
>> architectures such as one port to a point-to-point low latency link
> for
>> voice, another port to a frame relay or similar slower less QoS/CoS
> aware
>> protocol for e-mail, etc..  Based on the network address the router
> would
>> place the data packet on the correct WAN network port. Different
> length
>> queues could be set up for each port to keep all traffic flowing
> smoothly.
>>
>> Has any other organization given any thought to such an addressing
> scheme?
>>  Are there any problems that this would cause?
>>
>> It just seemed to make more sense from the wide area network
> perspective
>> than MPLS.  This scheme may also allow router resources such as CPU
>> cycles, to be dedicated to particular types of traffic - maybe there
> are
>> different router architectures that would be better with forwarding
> voice
>> packets over UDP others forwarding non-real time data over TCP.
>>
>> Steven Eiserman
>> Office of Information Technology/Infrastructure Management Division
>> Administrative Office of the U.S. Courts
>> [email-masked]
Begin forwarded message:

> From: "Dave Green" <[email-masked]>
> Date: January 30, 2007 7:45:10 AM PST
> To: [email-masked], "NAv6TF" <[email-masked]>
> Cc: "Stephen Oronte" <[email-masked]>
> Subject: RE: [nav6tf] IP Addressing Thoughts
>
> This is great - IPv6 lets us think "Out of the IPv4 Box" and  
> differentiate services in many ways.
>
> VOIP/SIP should be an E2E service with special handling, special  
> security, etc... different from routine client-server traffic like  
> e-mail and web browsing. SIP/VOIP addresses should be advertised  
> into a naming service (like DNS) and have special handling (IE the  
> firewall allows incoming) and - they need special QOS handling. If  
> your SIP/voip address block has a complete separate IP architecture  
> and different routing to get better QOS and an E2E model, great -  
> that's easy to do with IPv6 addressing. You could also achieve  
> multi-level security in that architecture with IPsec and priority  
> handling with flow labels, we just have to do the development to  
> make it happen. With the vast address space available, extension  
> headers, and flow labels in IPv6 you have a tool kit to accomplish  
> this sort of QOS+security differentiation for VOIP.
>
> I know that with the technology available today, we can do  
> simulation aided design and testing and rapidly prototype and  
> deploy the VOIP net Steven Eiserman is thinking of. We now have  
> great IP address management (IPAM) tools like IPAL and IPControl  
> that let us quickly design out different architectures with an IPv6  
> address space, then we can do virtual-live simulation with OPNET to  
> see the QOS difference with live phones before deploying it. The  
> technology is here to get this sort of return on investment from  
> utilizing IPv6 to help solve real problems - this is a great  
> example where tech investment dollars should be invested in IPv6  
> applications to improve actual operations. Going from "mandate" to  
> "mission" is what will get IPv6 in widespread use.
>
> David Green
> VP of Research and Development | Command Information
> 13655 Dulles Technology Drive, Herndon, VA 20171
> Office: 703.561.5937 | Mobile: +1-703-899-9663
> [email-masked]
>
>
> -----Original Message-----
> From: [email-masked] [mailto:owner- 
> [email-masked]] On Behalf Of Brett Thorson
> Sent: Tuesday, January 30, 2007 10:13 AM
> To: 'NAv6TF'
> Subject: [nav6tf] IP Addressing Thoughts
>
> I received this e-mail from a gentleman in our government.  He was
> wondering if we had any thoughts on his IP Addressing methodology.   
> I'll
> be happy to collect answers and post them to our soon to be FAQ.  I  
> have
> included his name and e-mail at the bottom (with his permission) so  
> if you
> wanted to CC him in on this discussion, feel free to do so.
>
> My own comment: I think it is great to see government entities that  
> aren't
> under the OMB mandate to be looking into IPv6.  Finally, people who
> understand!!
>
> --Brett
>
> A little background may help - I work for the Administrative Office  
> of the
> United States Courts, the third branch of the federal government.   
> We have
> a large WAN with more than 600 endpoints that is based on IPv4.
> Recognizing that the future will be here before we realize,  
> planning for
> IPv6 has started even though as the third branch, we are not bound  
> by OMB
> mandates, or other executive branch dictates.
>
> One of the issues we are looking at is how best to use the large  
> address
> space that IPv6 will provide. The addresses used in the current  
> network
> are distributed geographically.  This was originally done as the first
> iteration of our WAN was a hub-and-spoke architecture.
>
> One thought that came to mind was to distribute IPv6 addresses  
> based on
> the class of/quality of service required.  VOIP would get one range of
> addresses, non real-time data another, etc... - sort of like a big  
> brother
> to MPLS. Routers could be connected to different WAN backbone
> architectures such as one port to a point-to-point low latency link  
> for
> voice, another port to a frame relay or similar slower less QoS/CoS  
> aware
> protocol for e-mail, etc..  Based on the network address the router  
> would
> place the data packet on the correct WAN network port. Different  
> length
> queues could be set up for each port to keep all traffic flowing  
> smoothly.
>
> Has any other organization given any thought to such an addressing  
> scheme?
>  Are there any problems that this would cause?
>
> It just seemed to make more sense from the wide area network  
> perspective
> than MPLS.  This scheme may also allow router resources such as CPU
> cycles, to be dedicated to particular types of traffic - maybe  
> there are
> different router architectures that would be better with forwarding  
> voice
> packets over UDP others forwarding non-real time data over TCP.
>
> Steven Eiserman
> Office of Information Technology/Infrastructure Management Division
> Administrative Office of the U.S. Courts
> [email-masked]
Begin forwarded message:

> From: "Martin, Cynthia" <[email-masked]>
> Date: January 30, 2007 7:45:16 AM PST
> To: <[email-masked]>, "NAv6TF" <[email-masked]>
> Subject: RE: [nav6tf] IP Addressing Thoughts
>
> Good Morning,
>
> The IRS and other federal agencies are already testing this as part of
> their migration to an MPLS core with an IPv6 overlay.  It's a very  
> good
> migration strategy and solves some problems at the end system.
>
> -----Original Message-----
> From: [email-masked] [mailto:owner- 
> [email-masked]] On
> Behalf Of Brett Thorson
> Sent: Tuesday, January 30, 2007 10:13 AM
> To: 'NAv6TF'
> Subject: [nav6tf] IP Addressing Thoughts
>
> I received this e-mail from a gentleman in our government.  He was
> wondering if we had any thoughts on his IP Addressing methodology.   
> I'll
> be happy to collect answers and post them to our soon to be FAQ.  I  
> have
> included his name and e-mail at the bottom (with his permission) so if
> you
> wanted to CC him in on this discussion, feel free to do so.
>
> My own comment: I think it is great to see government entities that
> aren't
> under the OMB mandate to be looking into IPv6.  Finally, people who
> understand!!
>
> --Brett
>
> A little background may help - I work for the Administrative Office of
> the
> United States Courts, the third branch of the federal government.  We
> have
> a large WAN with more than 600 endpoints that is based on IPv4.
> Recognizing that the future will be here before we realize,  
> planning for
> IPv6 has started even though as the third branch, we are not bound by
> OMB
> mandates, or other executive branch dictates.
>
> One of the issues we are looking at is how best to use the large  
> address
> space that IPv6 will provide. The addresses used in the current  
> network
> are distributed geographically.  This was originally done as the first
> iteration of our WAN was a hub-and-spoke architecture.
>
> One thought that came to mind was to distribute IPv6 addresses  
> based on
> the class of/quality of service required.  VOIP would get one range of
> addresses, non real-time data another, etc... - sort of like a big
> brother
> to MPLS. Routers could be connected to different WAN backbone
> architectures such as one port to a point-to-point low latency link  
> for
> voice, another port to a frame relay or similar slower less QoS/CoS
> aware
> protocol for e-mail, etc..  Based on the network address the router
> would
> place the data packet on the correct WAN network port. Different  
> length
> queues could be set up for each port to keep all traffic flowing
> smoothly.
>
> Has any other organization given any thought to such an addressing
> scheme?
>  Are there any problems that this would cause?
>
> It just seemed to make more sense from the wide area network  
> perspective
> than MPLS.  This scheme may also allow router resources such as CPU
> cycles, to be dedicated to particular types of traffic - maybe  
> there are
> different router architectures that would be better with forwarding
> voice
> packets over UDP others forwarding non-real time data over TCP.
>
> Steven Eiserman
> Office of Information Technology/Infrastructure Management Division
> Administrative Office of the U.S. Courts
> [email-masked]
Begin forwarded message:

> From: "Davis, Terry L" <[email-masked]>
> Date: January 30, 2007 8:41:26 AM PST
> To: "Dave Green" <[email-masked]>,  
> <[email-masked]>, "NAv6TF" <[email-masked]>
> Cc: "Stephen Oronte" <[email-masked]>
> Subject: RE: [nav6tf] IP Addressing Thoughts
>
> Dave
>
> I've got a whole set of slides along these lines that I have  
> developed over the last half dozen years; it also works for in home  
> services.
>
> On the military side, it gives a theater commander especially a  
> whole set of options to merge his various services' networks too.   
> As the slides also point out, the guys on the military side could  
> also adopt their IFF coding to do part of the network authentication.
>
> Take care
> Terry
>
>> -----Original Message-----
>> From: Dave Green [mailto:[email-masked]]
>> Sent: Tuesday, January 30, 2007 7:45 AM
>> To: [email-masked]; NAv6TF
>> Cc: Stephen Oronte
>> Subject: RE: [nav6tf] IP Addressing Thoughts
>>
>> This is great - IPv6 lets us think "Out of the IPv4 Box" and  
>> differentiate
>> services in many ways.
>>
>> VOIP/SIP should be an E2E service with special handling, special  
>> security,
>> etc... different from routine client-server traffic like e-mail  
>> and web
>> browsing. SIP/VOIP addresses should be advertised into a naming  
>> service
>> (like DNS) and have special handling (IE the firewall allows  
>> incoming) and
>> - they need special QOS handling. If your SIP/voip address block  
>> has a
>> complete separate IP architecture and different routing to get  
>> better QOS
>> and an E2E model, great - that's easy to do with IPv6 addressing. You
>> could also achieve multi-level security in that architecture with  
>> IPsec
>> and priority handling with flow labels, we just have to do the  
>> development
>> to make it happen. With the vast address space available, extension
>> headers, and flow labels in IPv6 you have a tool kit to accomplish  
>> this
>> sort of QOS+security differentiation for VOIP.
>>
>> I know that with the technology available today, we can do simulation
>> aided design and testing and rapidly prototype and deploy the VOIP  
>> net
>> Steven Eiserman is thinking of. We now have great IP address  
>> management
>> (IPAM) tools like IPAL and IPControl that let us quickly design out
>> different architectures with an IPv6 address space, then we can do
>> virtual-live simulation with OPNET to see the QOS difference with  
>> live
>> phones before deploying it. The technology is here to get this  
>> sort of
>> return on investment from utilizing IPv6 to help solve real  
>> problems -
>> this is a great example where tech investment dollars should be  
>> invested
>> in IPv6 applications to improve actual operations. Going from  
>> "mandate" to
>> "mission" is what will get IPv6 in widespread use.
>>
>> David Green
>> VP of Research and Development | Command Information
>> 13655 Dulles Technology Drive, Herndon, VA 20171
>> Office: 703.561.5937 | Mobile: +1-703-899-9663
>> [email-masked]
>>
>>
>> -----Original Message-----
>> From: [email-masked] [mailto:owner- 
>> [email-masked]] On
>> Behalf Of Brett Thorson
>> Sent: Tuesday, January 30, 2007 10:13 AM
>> To: 'NAv6TF'
>> Subject: [nav6tf] IP Addressing Thoughts
>>
>> I received this e-mail from a gentleman in our government.  He was
>> wondering if we had any thoughts on his IP Addressing  
>> methodology.  I'll
>> be happy to collect answers and post them to our soon to be FAQ.   
>> I have
>> included his name and e-mail at the bottom (with his permission)  
>> so if you
>> wanted to CC him in on this discussion, feel free to do so.
>>
>> My own comment: I think it is great to see government entities  
>> that aren't
>> under the OMB mandate to be looking into IPv6.  Finally, people who
>> understand!!
>>
>> --Brett
>>
>> A little background may help - I work for the Administrative  
>> Office of the
>> United States Courts, the third branch of the federal government.   
>> We have
>> a large WAN with more than 600 endpoints that is based on IPv4.
>> Recognizing that the future will be here before we realize,  
>> planning for
>> IPv6 has started even though as the third branch, we are not bound  
>> by OMB
>> mandates, or other executive branch dictates.
>>
>> One of the issues we are looking at is how best to use the large  
>> address
>> space that IPv6 will provide. The addresses used in the current  
>> network
>> are distributed geographically.  This was originally done as the  
>> first
>> iteration of our WAN was a hub-and-spoke architecture.
>>
>> One thought that came to mind was to distribute IPv6 addresses  
>> based on
>> the class of/quality of service required.  VOIP would get one  
>> range of
>> addresses, non real-time data another, etc... - sort of like a big  
>> brother
>> to MPLS. Routers could be connected to different WAN backbone
>> architectures such as one port to a point-to-point low latency  
>> link for
>> voice, another port to a frame relay or similar slower less QoS/ 
>> CoS aware
>> protocol for e-mail, etc..  Based on the network address the  
>> router would
>> place the data packet on the correct WAN network port. Different  
>> length
>> queues could be set up for each port to keep all traffic flowing  
>> smoothly.
>>
>> Has any other organization given any thought to such an addressing  
>> scheme?
>>  Are there any problems that this would cause?
>>
>> It just seemed to make more sense from the wide area network  
>> perspective
>> than MPLS.  This scheme may also allow router resources such as CPU
>> cycles, to be dedicated to particular types of traffic - maybe  
>> there are
>> different router architectures that would be better with  
>> forwarding voice
>> packets over UDP others forwarding non-real time data over TCP.
>>
>> Steven Eiserman
>> Office of Information Technology/Infrastructure Management Division
>> Administrative Office of the U.S. Courts
>> [email-masked]

_______________________________________________
RAM mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ram

---

From: Ruri Hiromi <[email-masked]>
Date: Wed, 31 Jan 2007 15:41:22 +0900

Hello,

Can I ask you to feed me back what is the afraid point?

On 2007/01/31, at 8:32, Fred Baker wrote:

>> your SIP/voip address block has a complete separate IP  
>> architecture and different routing to get better QOS and an E2E  
>> model, great - that's easy to do with IPv6 addressing. You could  
>> also achieve multi-level security in that architecture with IPsec  
>> development to make it happen. With the vast address space  
>> available, extension headers, and flow labels in IPv6 you have a  
>> tool kit to accomplish this sort of QOS+security differentiation  
>> for VOIP.
>>
>> that let us quickly design out different architectures with an  
>> IPv6 address space, then we can do virtual-live simulation with  
>> OPNET to see the QOS difference with live phones before deploying  
>> it. The technology is here to get this sort of return on  
>> investment from utilizing IPv6 to help solve real problems - this  
>> is a great example where tech investment dollars should be  
>> invested in IPv6 applications to improve actual operations. Going  
>> from "mandate" to "mission" is what will get IPv6 in widespread use.
>>
>> David Green
>> developed over the last half dozen years; it also works for in  
>> home services.
>>
>>> headers, and flow labels in IPv6 you have a tool kit to  
>>> accomplish this
>>> simulation
>>> aided design and testing and rapidly prototype and deploy the  
>>> VOIP net
>>> United States Courts, the third branch of the federal  
>>> government.  We have
>>> IPv6 has started even though as the third branch, we are not  
>>> bound by OMB
>>> addresses, non real-time data another, etc... - sort of like a  
>>> big brother
>>> Has any other organization given any thought to such an  
>>> addressing scheme?

-------------------------------
Ruri Hiromi
[email-masked]

---

From: <[email-masked]>
Date: Wed, 31 Jan 2007 11:36:05 +0200

If one would only receive similar letters from ISPs/operators. But why
would they bother? NATs are these T.rexes' new but eventually fruitless
way to keep competitors at distance. 

Meanwhile the evolution is extending the IPv4 address with the 16 bit
port number (STUN, STUN relay, TURN, ICE, UPnP IGD, Skype, etc.). 

/Mikael
 
>> aren't under the OMB mandate to be looking into IPv6.  
>Finally, people 
>> who understand!!
>>
>> --Brett

---

From: Fred Baker <[email-masked]>
Date: Wed, 31 Jan 2007 02:10:31 -0800

Remind me: how does address aggregation work in this?

On Jan 30, 2007, at 10:41 PM, Ruri Hiromi wrote:

>>>> government.  We
>>>> planning
>>>> bound by
>>>> based
>>>> there
>>> security, etc... different from routine client-server traffic  
>>> like e-mail and web browsing. SIP/VOIP addresses should be  
>>> advertised into a naming service (like DNS) and have special  
>>> handling (IE the firewall allows incoming) and - they need  
>>> special QOS handling. If your SIP/voip address block has a  
>>> better QOS and an E2E model, great - that's easy to do with IPv6  
>>> addressing. You could also achieve multi-level security in that  
>>> architecture with IPsec and priority handling with flow labels,  
>>> we just have to do the development to make it happen. With the  
>>> vast address space available, extension headers, and flow labels  
>>> in IPv6 you have a tool kit to accomplish this sort of QOS 
>>> +security differentiation for VOIP.
>>>
>>> their migration to an MPLS core with an IPv6 overlay.  It's a  
>>> very good
>>> government.  We
>>> bound by
>>> whole set of options to merge his various services' networks  
>>> too.  As the slides also point out, the guys on the military side  
>>> could also adopt their IFF coding to do part of the network  
>>> authentication.
>>>
>>> Take care
>>> Terry
>>>
>>>> could also achieve multi-level security in that architecture  
>>>> with IPsec
>>>> virtual-live simulation with OPNET to see the QOS difference  
>>>> with live
>>>> be happy to collect answers and post them to our soon to be  
>>>> FAQ.  I have

---

From: Geoff Huston <[email-masked]>
Date: Wed, 31 Jan 2007 21:37:49 +1100

>Remind me: how does address aggregation work in this?

Precisely!

If you are thinking about linking a QoS response to some 
pre-determined set of values somewhere in the packet header then 
we've already had a whole heap of fun with the old TOS field, and 
then a subsequent foray into dynamic filter sets with Intserv 
followed by the exploration of a redefined TOS field with Diffserv. 
We've thought from time to time about forms of QoS-distinguished 
routing.  Each of these approaches have had their issues when 
attempting to think about deployment issues in spaces of the 
dimension and shape of the public Internet. With this wealth of 
experience I would've thought that by now we've learned a little bit 
about driving specialized network responses over the years and one of 
those lessons is that the address field in the packet header is 
probably a pretty poor starting point to use to place service 
response signalling information.

   Geoff

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 31 Jan 2007 11:57:11 +0100

> Can I ask you to feed me back what is the afraid point?

Just to repeat what I wrote to another list on this
proposal:

...it makes no sense in a world where VoIP, video, and traditional
services are mixed on the same subnets and the same devices, which may be
mobile anyway. When I use my IP phone it has its own IP address; when I
fire up my softphone, it takes over the same SIP and PSTN identity using
a different IP address, sometimes on the same wire and sometimes on
another continent. Trying to resolve the associated QoS challenges by
playing with IP addresses isn't just a layer violation and extra
semantic overloading of addresses: more important, it simply won't work.

    Brian

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Wed, 31 Jan 2007 15:10:38 +0100

On 31-jan-2007, at 11:57, Brian E Carpenter wrote:

> more important, it simply won't work.

So when has that ever stopped anyone?

Obviously the problems are real, but I can see some value in an  
approach like this. For instance, for VoIP it's important to give  
VoIP traffic a higher priority than some other types of traffic. For  
outgoing traffic this is easy to do by looking at port numbers or  
diffserv code points, but for incoming traffic that's much harder:  
essentially, you need to tell an ISP how to deal with different kinds  
of traffic in a great amount of detail. On the other hand, if  
different kinds of traffic are directed towards different addresses,  
it's extremely easy to have them flow into different funnels using  
standard routing protocols.

Maybe others have a better view of this, but it's completely unclear  
to me how real time traffic over the internet is going to play out in  
the future. I.e., at some point the last TDM equipment will be hauled  
off to the scrap heap and we'll all be doing phone calls over IP.  
Note that this is a completely different situation from what we have  
today, I wouldn't exactly call current phone calls over IP "voice  
over IP" but rather "last mile over IP" because when calling between  
different service providers, there's always (> 99%) still a TDM  
exchange in the middle.

Anyway, at this point, it's necessary for phone company A to have  
VoIP packets find their way across a big IP network towards phone  
company B. How is this going to work? I don't think phone companies  
will like the idea of using publicly routable IP addresses that are  
subject to DoS attacks and so on. On the other hand, with several  
thousand phone companies world wide, building a private network  
doesn't really work all that well. Classic case of the irresistible  
force vs the immovable object.

I don't see a clear best way to do this, which probably means that  
many people will do it in many different ways and it will take a long  
time for all of this to work itself out.

What was so bad about TDM that it needed replacement again?

---

From: Eliot Lear <[email-masked]>
Date: Wed, 31 Jan 2007 15:18:26 +0100

> Remind me: how does address aggregation work in this?
Within the IGP an Nx hit.  Reminds me a whole lot of OSPF with TOS.

Eliot

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 31 Jan 2007 15:57:26 +0100

I don't get your issue with incoming traffic. Diffserv
(or flow label, or IntServ, or NSIS) are all designed
to work all along the path.

Why will there be phone companies, once SIP goes peer to peer?

Things are going to be very different a few years from now.
Any semantics we try to impose on addresses today will
very likely just look quaint ten years from now.

     Brian

On 2007-01-31 15:10, Iljitsch van Beijnum wrote:
> Obviously the problems are real, but I can see some value in an approach 
> like this. For instance, for VoIP it's important to give VoIP traffic a 
> higher priority than some other types of traffic. For outgoing traffic 
> this is easy to do by looking at port numbers or diffserv code points, 
> but for incoming traffic that's much harder: essentially, you need to 
> tell an ISP how to deal with different kinds of traffic in a great 
> amount of detail. On the other hand, if different kinds of traffic are 
> directed towards different addresses, it's extremely easy to have them 
> flow into different funnels using standard routing protocols.
> 
> Maybe others have a better view of this, but it's completely unclear to 
> me how real time traffic over the internet is going to play out in the 
> future. I.e., at some point the last TDM equipment will be hauled off to 
> the scrap heap and we'll all be doing phone calls over IP. Note that 
> this is a completely different situation from what we have today, I 
> wouldn't exactly call current phone calls over IP "voice over IP" but 
> rather "last mile over IP" because when calling between different 
> service providers, there's always (> 99%) still a TDM exchange in the 
> middle.
> 
> Anyway, at this point, it's necessary for phone company A to have VoIP 
> packets find their way across a big IP network towards phone company B. 
> How is this going to work? I don't think phone companies will like the 
> idea of using publicly routable IP addresses that are subject to DoS 
> attacks and so on. On the other hand, with several thousand phone 
> companies world wide, building a private network doesn't really work all 
> that well. Classic case of the irresistible force vs the immovable object.
> 
> I don't see a clear best way to do this, which probably means that many 
> people will do it in many different ways and it will take a long time 
> for all of this to work itself out.
>

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Wed, 31 Jan 2007 18:20:01 +0100

> to work all along the path.

Sure. But if you were to call me over the net at [email-masked]  
(which works, by the way, when I remember to run my SIP client, but  
nobody ever phones me at my email address so I tend to forget) then  
I'm in control of the diffserv bits on the packets from me to you  
(I'm using diffserv because all the other stuff that I'm familiar  
with has an even lower chance of working) so I can mark the VoIP  
packets and make sure they're treated better than bulk stuff when  
they hit my connection to the internet, which is presumably a  
bottleneck as my internal network is much faster not to mention all  
the ISP networks along the way. So my exit router does its smart  
queuing and life is good.

But when I stop talking and you say something, packets flow in the  
other direction. The bottleneck is the same, but for incoming  
packets, it's the ISP's router (or worse, layer 2 device, remember  
that most DSL and cable runs over ATM) that has to do the smart  
queuing. Suppose they use a simple diffserv setup where there is one  
code point that gets preferential treatment. This would work  
reasonably well for outgoing traffic, because there I (my  
applications, OS ro router) set the code point, but for incoming  
traffic there is no way to make sure only VoIP packets have the high  
priority code point. An attacker would very likely use packets with  
all possible code points, for instance.

> Why will there be phone companies, once SIP goes peer to peer?

Very likely, if we define "phone company" as "corporation that guards  
access to a large scale communication network and imposes arbitrary  
restrictions and high fees".

What we see today is the US model where basically, you have a choice  
(if you're lucky) between cable and DSL for broadband, and a  
different model here in the Netherlands where you can get DSL from  
many people but they all go over the same monopoly telco wires. Note  
though that with fiber to the home you probably won't have any choice  
after the fiber is installed, because internet, phone and TV service  
will all run over that same fiber.

The organization in control of the access network is in the best  
position to deliver high quality VoIP because they can give their own  
VoIP and other real time services higher priority on the access  
network while competitors must work at the "normal" priority and  
compete with bulk traffic. There are also some long distance  
backhauling advantages but those probably don't mean much for voice.  
The ability to keep these services separate from regular internet  
traffic is also important security-wise. This is where different  
addresses for different services can help. In enterprise networks  
we're probably going to see that too: it's probably cheaper in the  
long run to have a dedicated VoIP wireless network rather than have  
one big wireless network but suffer from the problems we tend to see  
during IETF meeting plenaries.

> very likely just look quaint ten years from now.

A good reason to keep them as semantic-free as possible.

---

From: Roland Bless <[email-masked]>
Date: Wed, 31 Jan 2007 22:44:13 +0100

Hi,

Iljitsch van Beijnum wrote:
> preferential treatment. This would work reasonably well for outgoing
> traffic, because there I (my applications, OS ro router) set the code
> point, but for incoming traffic there is no way to make sure only VoIP
> packets have the high priority code point. An attacker would very likely
> use packets with all possible code points, for instance.

Two comments:
1) An essential point in the DiffServ architecture
is the first-hop router that either should set the DSCP
or should not accept any DiffServ packet markings unless
that flow was admitted (by a corresponding policy). So boundary
routers must strictly protect DiffServ regions from non-admitted
traffic, otherwise guarantees are at risk...
2) QoS Signaling: Protocols for signaling the network in order to provide
the necessary differentiation for (some of) your incoming flows
are currently standardized in the NSIS WG. Optimally this would
go to the other end and start there (e2e signaling and QoS), but
signaling your provider in order to turn on DiffServ at the
last hop router may be a start...however, you need support
from the network and the applications for QoS signaling...

Regards,
 Roland

---

From: Andrew Lange <[email-masked]>
Date: Wed, 31 Jan 2007 14:08:32 -0800

Resent now that I updated my subscribed email address to match the from.

On Jan 31, 2007, at 6:10 AM, Iljitsch van Beijnum wrote:

> VoIP traffic a higher priority than some other types of traffic.
>

This point is often made, but without too much consideration as to  
where prioritization is useful.  Priority schemes are useful ONLY  
when there is contention for resources on the line.  A network is  
usually designed to handle peak loads without congesting (mother's  
day load in the US voice networks), after all a carrier does not want  
to turn away business if they don't have to do so.  In addition, this  
metric has been expanded to include "peak load under worst-case  
single failure." And with the advent of IP, this can be done without  
needing to double the bandwidth with a SONET/SDH working and protect  
path.  Admittedly, not all networks are designed to this standard for  
a variety of reasons (too expensive, resources not available, etc.)  
If a network has the resources available, there is no need for a  
marking or prioritization scheme.  In the most usual state the  
network will have resources available in most places.  Any QoS scheme  
needs to be designed with an eye toward being lightweight to address  
the very real case that it will not be necessary most of the time.  
This point may be obvious, but it is often overlooked.

> For outgoing traffic this is easy to do by looking at port numbers  
> or diffserv code points, but for incoming traffic that's much  
> harder: essentially, you need to tell an ISP how to deal with  
> different kinds of traffic in a great amount of detail. On the  
> other hand, if different kinds of traffic are directed towards  
> different addresses, it's extremely easy to have them flow into  
> different funnels using standard routing protocols.
>

The issue here is not a technical one, it is an issue of trust.  Does  
your operator trust you to mark your VoIP packets correctly, and in a  
way meaningful to that operator?  If your operator is like those I  
have experience with, then the answer is no.  Any markings that are  
received from a foreign network are either 1) quashed or 2) rewritten  
to something locally meaningful.  The incoming marking (p-bit,  
diffserv, mpls exp) is only one handle on which the QoS remarking  
might be done (others are things like port number or virtual circuit).

Along these bilateral lines, if we reexamine the VoIP example between  
two interlocutors A and B:

 From A to B:

A "marking 1" --> DSLAM  ---> PE(Y), remarked into "VoIP/EF class",  
billing counter optionally incremented/
---> P(Y) --> PE(Y) to provider X with marking "W", meaning "VoIP"  
based on their bi-lateral contract/
---> peering link to X ---> PE(X), remarks "W" into "Z", meaning  
"VoIP" in their QoS scheme ---> P(X)/
---> PE(X) (optionally incrementing billing counter) ---> DSLAM --->  
B's local router, which remarks/
  "Z" back into "marking 1"

 From B to A:

The same thing happens in reverse.  There is no problem with the  
reverse path for the markings, because the markings are done network- 
by-network into locally significant values.

These examples assume that the DSLAM is set to understand and respect  
"marking 1" as having some meaning.

This also assumes that there are no Media Gateways, SIP Proxies or  
other application-specific devices in the data or signaling path.    
This wouldn't change the QoS model, but the drawing would change.

How this is handled is an administrative trust and contractual issue  
between the two networks involved.  As protocol designers, we must  
make sure that this sort of thing is supported in a flexible manner  
to operators can do with it as best meets their needs.

> Maybe others have a better view of this, but it's completely  
> unclear to me how real time traffic over the internet is going to  
> play out in the future. I.e., at some point the last TDM equipment  
> will be hauled off to the scrap heap and we'll all be doing phone  
> calls over IP. Note that this is a completely different situation  
> from what we have today, I wouldn't exactly call current phone  
> calls over IP "voice over IP" but rather "last mile over IP"  
> because when calling between different service providers, there's  
> always (> 99%) still a TDM exchange in the middle.
>

There will be a network of bilateral peering arrangements between  
networks that say "If I send you marking A that means "Video", please  
treat it as you treat "Video" on your network."  And there may be  
billing arrangements between the networks for different contracts of  
carriage, depending on the economics.  The need for differentiated  
services will be low if the risk of application degradation due to  
congestion is low.  The more resilient bandwidth we have everywhere  
the less valuable treating bits differently becomes.  QoS will exist  
as an insurance policy against failure and for high-bandwidth  
applications (streaming sports events in HDTV, for example).

> force vs the immovable object.

If an operator want to separate traffic based on application that can  
be done with VPNs today there is no need for IPv6 to do this.   
Separation is done on a per-network basis, with a gateway function  
between network to remap QoS, or NAT, if required.

Andrew

> many people will do it in many different ways and it will take a  
> long time for all of this to work itself out.
>

---

From: Roland Bless <[email-masked]>
Date: Wed, 31 Jan 2007 23:48:36 +0100

Hi Andrew,

[comments inline]

Andrew Lange wrote:
> prioritization is useful.  Priority schemes are useful ONLY when there
> is contention for resources on the line.  A network is usually designed
> to handle peak loads without congesting (mother's day load in the US
> voice networks), after all a carrier does not want to turn away business
> if they don't have to do so.  In addition, this metric has been expanded
> to include "peak load under worst-case single failure." And with the
> advent of IP, this can be done without needing to double the bandwidth
> with a SONET/SDH working and protect path.  Admittedly, not all networks
> are designed to this standard for a variety of reasons (too expensive,
> resources not available, etc.) If a network has the resources available,
> there is no need for a marking or prioritization scheme.  In the most
> usual state the network will have resources available in most places. 
> Any QoS scheme needs to be designed with an eye toward being lightweight
> to address the very real case that it will not be necessary most of the
> time. This point may be obvious, but it is often overlooked.

Sure, QoS mechanisms are only required when there is resource
shortage. However, "overprovisioned" networks don't provide
enough protection against DDoS (here: flooding attacks).
So I know at least one provider that introduced prioritized
VoIP traffic in order to protect it against congestion
caused from "normal" traffic, e.g. caused during DDoS flooding
attacks (congestion may be caused in the direction
towards access networks, i.e. when descending the bandwidth
hierarchy). This makes sense to me...

>> For outgoing traffic this is easy to do by looking at port numbers or
> way meaningful to that operator?  If your operator is like those I have

Yep.

> experience with, then the answer is no.  Any markings that are received
> from a foreign network are either 1) quashed or 2) rewritten to
> something locally meaningful.  The incoming marking (p-bit, diffserv,
> mpls exp) is only one handle on which the QoS remarking might be done
> (others are things like port number or virtual circuit).

Correct.

Regards,
 Roland

---

From: Andrew Lange <[email-masked]>
Date: Wed, 31 Jan 2007 15:12:30 -0800

Hi Roland,

One reply is inline.

> hierarchy). This makes sense to me...

Yes, absolutely.  The typical congestion point is going to be in the  
access network, and most likely in the "2nd" mile between the DSALM/ 
CMTS and the upstream network.  This if often where the most  
oversubscription takes place.  If this gets congested then needing a  
mechanism to help more sensitive applications' traffic get through  
makes a lot of sense.  But this point is not going to be congested  
all day (one would hope ;-), and the rest of the communications path  
would likely be fine.  This reinforces my point about needing a  
lightweight, flexible mechanism to address transient and localized  
congestion.

Andrew