Subject: [Speermint] Review of draft-ietf-speermint-architecture-04

From: Otmar Lendl <[email-masked]>
Date: Wed, 28 Nov 2007 14:28:35 +0100

I can't remember that we discussed that draft during the last two
meetings. The current agenda gives 40 mins for this draft, so took
another look at this document.

>Abstract 
>
>   This document defines the SPEERMINT peering architecture, its  
>   functional components and peering interface functions. It also 
>  describes the steps taken to establish a session between two peering   

General comment: 

We now finally have once again a document which lists the requirements
on what the speermint architecture is supposed to solve. That list
isn't done yet, but still it would be worthwhile to look at the
architecture document with an eye for the requirements.

As the requirements draft changed substantially recently, this draft
also needs to reflect this.

>2. Network Context  
>
> 
>   Figure 1 shows an example network context. 

I find this figure to be more confusing than helping.

>   Two SIP providers can form  
>   a Layer 5 peer over either the public Internet or private Layer 3  
>   networks. In addition, two or more providers may form a SIP (Layer 5)  
>   federation [17] on either the public Internet or private Layer 3  
>   networks. This document does not make any assumption whether the SIP  
>   providers directly peer to each other or through Layer 3 transit  
>   network as per use case of [16].   

fine.

> 
>   Note that Figure 1 allows for the following potential SPEERMINT  
>   peering scenarios:  
> 
>   o  Enterprise to Enterprise across the public Internet  
> 
>   o  Enterprise to Service Provider across the public Internet  
> 
>   o  Service Provider to Service Provider across the public Internet  
> 
>   o  Enterprise to enterprise across a private Layer 3 network  
> 
>   o  Enterprise to Service Provider across a private Layer 3 network  
> 
>   o  Service Provider to Service Provider across a private Layer 3  
>      network  

I see no reasons to treat Enterprises any different from Service
Providers. Yes, there may be legal and regulatory issues specific to
these cases, but from a pure protocol point of view, I see no need
to add this distinction. (BGP doesn't care whether layer 3 peering
partners are ISPs or enterprises, too.)

>   The members of a federation may jointly use a set of functions such  
>   as location peering function, application function, subscriber  
>   database function, SIP proxies, and/or functions that synthesize  
>   various SIP and non-SIP based applications. Similarly, two providers  
>   may jointly use a set of peering functions. The federation functions  
>   or the peering functions can be either public or private.  

Hu? 

>3. Procedures  
>
> 
>   This document assumes that a call from an end user in the initiating  
>   peer goes through the following steps to establish a call to an end  
>   user in the receiving peer:   
> 
>         1. The analysis of a target address.   
> 
>             a. If the target address represents an intra-VSP resource,  
>                we go directly to step 4.  

SSP, not VSP. 

Case a. doesn't fit in here as we're considering calls to other SSPs.
(we're not covering calls to voicemail and other types of calls, either.)

So what's the result of this analysis?

>         2. the discovery of the receiving peering point address,  

Does this include the determination of whether there is a peering?

> 
>         3. the enforcement of authentication and other policy,  
> 
>         4. the discovery of end user address,   
> 
>         5. the routing of SIP messages,  
> 
>         6. the session establishment,   
> 
>         7. the transfer of media,  
> 
>         8. and the session termination.   
> 
>4. Reference SPEERMINT Architecture  
> 
>   The procedures presented in Chapter 3 are implemented by a set of  
>   peering functions:   
>
>   o  Location Function (LF): Purpose is to develop Session  
>      Establishment Data (SED) by discovering the Signaling Function 
>     (SF) and the end user's reachable host (IP address and port). The 

I'm not sure whether we should include purely internal functions
in this document. For all we care, the terminating SSP could
route all calls to voicemail, to a PSTN gateway, to a H.323 gate,
to a Skype gateway or whatnot.

>      location function is distributed across the Location Server (LS)  
>      and Session Manager (SM). 
> 
>5.1. The Location Function (LF) of an Initiating Provider  
>
>   Purpose is to develop Session Establishment Data (SED) [12] by 
>   discovering the Signaling Function (SF), and end user's reachable 
>   host (IP address and host). The LF of an Initiating provider analyzes   
>   target address and discovers the next hop signaling function (SF) in 
>   a peering relationship using DNS, SIP Redirect Server, or a  
>   functional equivalent database.    

Good. As this is the crux of the matter, I recommend to either
completely strike the DNS/SIP/DB half-sentence or *really* explain
what happens.

>5.1.1. Target address analysis  
>
>   When the initiating provider receives a request to communicate, the  
>   initiating provider analyzes the target state data to determine  
>   whether the call needs to be terminated internal or external to its  
>   network. The analysis method is internal to the provider's policy;  
>   thus, outside the scope of SPEERMINT. Note that the peer is free to  
>   consult any manner of private data sources to make this  
>   determination.  
> 
>   If the target address does not represent a resource inside the  
>   initiating peer's administrative domain or federation of domains, the  
>   initiating provider resolves the call routing data by using the  
>   Location Function (LF). Examples of the LF are the functions of ENUM,  
>   Routing Table, SIP DNS, and SIP Redirect Server.  

As above, this is TAMO.  (then a miracle occurs)

>5.1.3. Carrier ENUM lookup  

Infrastructure ENUM.

>
>   Next the initiating peer checks for a carrier-of-record in a carrier  
>   ENUM domain according to the procedures described in [12].  As in the  
>   previous step, the peer MAY consult a cache or alternate  
>   representation of the ENUM data in lieu of actual DNS queries.  The  
>   peer first checks for records for the "E2U+sip" enumservice, then for  
>   the "E2U+pstn" enumservice as defined in [21].  If a terminal record  
>   is found with a sip: or sips: URI, the peer skips to Section 5.1.5,  
>   otherwise the peer continues processing according to the next  
>   section.  

See comment to 5.2.1

> 
>5.1.4. Routing Table  
>
>   If there is no user ENUM records and the initiating peer cannot  
>   discover the carrier-of-record or if the initiating peer cannot reach  
>   the carrier-of-record via SIP peering, the initiating peer still  
>   needs to deliver the call to the PSTN or reject the call.  Note that  
>   the initiating peer MAY still sends the call to another provider for  
>   PSTN gateway termination by prior arrangement using a routing table.   
>   If so, the initiating peer rewrites the Request-URI to address the  
>   gateway resource in the target provider's domain and MAY forward the  
>   request on to that provider using the procedures described in the  
>   remainder of these steps.  

The indirect peering option is missing here. There could be a transit SSP
who does noch act as PSTN gateway, but simply as SIP hop.

> 
>5.1.5. SIP DNS Resolution  
>
>   Once a sip: or sips: in an external domain is selected as the target, 
>   the initiating peer MAY apply local policy to decide whether 
>   forwarding requests to the target domain is acceptable.  

Well, maybe the target domain also has some say in whether it
will accept calls via SIP from the originating domain.

again, see comment to 5.2.1.

>5.1.6. SIP Redirect Server    
>
>   A SIP Redirect Server may help in resolving current address of a  
>   mobile target address.  

hu?

"mobile" in the sense of nomadic use, i.e. the current IP address
of the user's phone? No, that's LF territory. 

"mobile" in the sense of fixed/mobile convergence? Number porting?
You lost me here.

>5.2. The Location Function (LF) of a Receiving Provider  
>
>5.2.1. Publish ENUM records  
>
>   The receiving peer SHOULD participate by publishing "E2U+sip" and  
>   "E2U+pstn" records with sip: or sips: URIs wherever a public carrier  
>   ENUM root is available.  This assumes that the receiving peer wants  
>   to peer by default.  Even when the receiving peer does not want to  
>   accept traffic from specific initiating peers, it MAY still reject  
>   requests on a case-by-case basis.  

This is one of the core questions for the whole speermint architecture.

I do not think we can assume that a receiving peer wants to peer by default.
Quite to the contrary: As I see it, the primary reason for the existence
of speermint is that fact that this is NOT TRUE. If it were true, then
RFC3261/3263 plus ENUM would be sufficient for universal SIP interconnection.

Can we *please* get consensus on this question in Vancouver?

Second question:

	Assuming what the receiving peer will only accept calls from
	specific initiating peers, can we handle the rejections on 
	the SIP layer?

My answer (from
http://www.enum.at/ietf/draft-lendl-sip-peering-policy-00.html on) has
always been that we cannot do that. The main reasons are that some SSPs
will elect to only run SIP ingress points within private interconnection
networks and not on the public Internet. Or if they do, they will be
firewalled so that INVITES from unwanted peers will be rejected on the
IP layer. Others might place restrictions on the TLS parameters of
incoming SIP connection: when the wrong TLS certs are presented, no SIP
communication is possible.

Once again, can we get this sorted out in Vancouver?

> 
>5.2.2. Publish SIP DNS records  
>
>   To receive peer requests, the receiving peer MUST insure that it    
>   publishes appropriate NAPTR, SRV, and address (A and/or AAAA) records     
>   in the global DNS that resolve an appropriate transport, port, and    
>   address to a relevant SIP server.    

How does this square with

      Requirement #3: the mechanisms recommended for the declaration and
      advertisement of SBE and SDE entities must allow for peer and
      media variability.

      Notes on solution space: for advertising peer-dependent SBEs (peer
      variability), the solution space based on is under specified and
      there are no know best current practices. 

from the requirements draft?

>5.4.1. Setup TLS connection 
>
>   Once a transport, port, and address are found, the initiating peer 
>   will open or find a reusable TLS connection to the peer.  The 
>   initiating provider MUST verify the server certificate which SHOULD 
>   be rooted in a well-known certificate authority.  The initiating 
>   provider MUST be prepared to provide a TLS client certificate upon 
>   request during the TLS handshake.  The client certificate MUST 
>   contain a DNS or URI choice type in the subjectAltName which 
>   corresponds to the domain asserted in the host production of the From 
>   header URI.  The certificate SHOULD be valid and rooted in a well- 
>   known certificate authority. 

How does this work in the case on the second leg of an inderect peering?
In that case the domain in the From: header does not belong the transit
SSP.

> 
>   Note that the client certificate MAY contain a list of entries in the 
>   subjectAltName, only one of which has to match the domain in the From 
>   header URI. 

Can this work if customer-owned domains hosted with SSPs take off
the same way they did for e-mail? In other words, what happens when
ATT hosts the SIP service for a few thousand domains?

>   SHOULD be a global-number.  For example, the following are all 
>   acceptable, the first three are encouraged: 
> 
>   From: "John Doe" <[email-masked]> 
>   From: "+12125551212" <[email-masked];user=phone> 
>   From: "Anonymous" <[email-masked]> 

This is fine.

>5.5.2. Receive SIP requests 
>
>   Once a TLS connection is established, the receiving peer is prepared 
>   to receive incoming SIP requests.  For new dialog-forming requests 
>   and out-of-dialog requests, the receiving peer verifies that the 
>   target (request-URI) is a domain which for which it is responsible. 

Once again, this does not seem to cover indirect peering.

> 
>   The receiving peer MAY reject incoming requests due to local policy. 
>   When a request is rejected because the initiating peer is not 
>   authorized to peer, the receiving peer SHOULD respond with a 403 
>   response with the reason phrase "Unsupported Peer". 

What is the initiating peer supposed to do in this case?

* For E.164 number based dialing, it could bounce the call to the PSTN.

* For SIP URI dialed calls: ???

Perhaps there is a path via a transit SIP operator? How will the initiating
peer learn about this other path?

>6. Call Control and Media Control Deployment Options  
>
>   In a decomposed model, SF and MF are implemented in separate peering  
>   logical elements. Signaling functions are implemented in a proxy and  
>   media functions are implemented in another logical element.  The  
>   scaling of signaling versus scaling of media may differ between  
>   applications.  Decomposing allows each to follow a separate migration  
>   path.  

Is the protocol between the SF and the MF in scope for speermint? 
I have no clue what is used there.

>
>7. Address space considerations  
>

fine.

Let the discussion begin.

/ol
-- 
/ Otmar Lendl <[email-masked]>, T: +43 1 5056416 - 33, F: - 933 \
| nic.at Internet Verwaltungs- und Betriebsgesellschaft m.b.H |
\ http://www.nic.at/  LG Salzburg, FN 172568b, Sitz: Salzburg /

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

---

From: Pat MeLampy <[email-masked]>
Date: Wed, 28 Nov 2007 17:45:10 -0500

The real body of standards work that is necessary for this group to accomplish is now at hand. If one were to look at these use cases, a crying need for standards development exists. Let me be specific.

5.1.1-4 Talks about directing a call to a domains SM
5.1.2-3 Talks about directing a call to a domans SBE
5.2.1-3 Talks about selecting both a O-SBE and T-SBE for a destination
6.1-3 Talks about next-hop IP address resolution

Already there is a great ongoing debate about how to provision all of the databases and ENUM servers used in these steps above. I wanted to suggest that this entire scheme needs to be discussed in greater detail as this working group moves forward. Consider the following...

1.) Cingular (ATT) reported that it had 51 million subscribers in June of 2005. I'm sure they have many more now.

Now lets make some working assumptions

1.) With a 11% busy hour, there would be 5.61 million users on their phone
2.) Assuming 40% were "outbound network terminations", this would mean there would be 2.244 million outbound peering calls
3.) Assuming 20% were "inbound network terminations", this would mean there would be 1.122 million inbound peering calls
3.) Assuming a 3 minute call hold time, this would create a PEERING call signaling rate of 18,700 calls per second (successful calls).
4.) Assuming an Answer Seizure Ration of 80%, then the number of call signaled attempts would be 23,375 per second
5.) The number of GiGE's to support the media traffic would be 420, or 42 10GigE's
6.) The number of stateless proxies (assuming 2000 CPS) would be 12.
7.) The number of SBE proxies (assuming 200 CPS) would be 120.

Not knowing anything about this network in particular, my guess is there would be an attempt to have DBE regionally to optimize media path. The number of locations and size of each location is not easy for me to contemplate -- but for illustrative purposes, lets say there are 40 locations where there is a desire to have DBE equipment for optimized media flows.

Now the fun part.....

For the simplest use case of direct peering, and in the simplest case, assume the carrier is identical in size. The carriers on both sides have the same number of elements in equal proportion. So here is what we have...

40 physical locations -- at which there are:
a.) 120 SBE's facing 120 SBE's across a direct peering border
b.) somewhere between 42 and 420 DBE's on each side facing each other
c.) At least 12 routing proxies on each side sending calls to the 120 SBE's.

The ability to provision this equipment, and share the IP Addresses with both sides, and maintain the service state of these physical links is not trivial. Data must be exchanged to expose SBE addresses, and consequently DBE addresses for use. This is clearly within the Scope of this working group in my opinion.

The belief that a routing proxy can "hunt and peck" its way to an open channel is simply impossible. There needs to be a serious look at taking the advertised capabilities exchange that must occur to provision and manage this direct relationship and using that information along with some 'soft state' about rates and loads to solve this problem. There is no way an ENUM server or data base without network state than can solve the routing problem we have here.

Said another way, until we look at making the layer 5 routing schemes parallel the way layer 3 routing schemes work, we will never reach the kind of scale I have presented here. If you want to really complicate the problem consider this reasonable guess. If our sample customer (ATT) were to have 100% IP Peering in the future -- it would be distributed something like...

1.) 15% to Sprint
2.) 20% to Verizon Wireless
3.) 10% to Verizon Wireline
3.) 20% to ATT Wireline
4.) 10% to Qwest
5.) 15% to a large host of others

CONCLUSION:

Static location functions and ENUM functions can be very useful in locating a Terminating SSP Domain

BUT ...

We need a set of network protocols that can establish and maintain routing information bases that can make this kind of interconnection work with scale in a very dynamic way. I think this working group is only just beginning.

---

From: "Michael Hammer (mhammer)" <[email-masked]>
Date: Thu, 29 Nov 2007 09:22:03 -0500

Otmar,

Agree with the sentiment that the enterprise v. carrier distinction
should have no effect on the protocol aspects.  However, it still needs
to be identified so that folks don't lose sight of it and design some
roadblock into the protocol work that would prevent enterprises from
using it.  The technical details can have a way of wandering if we lose
sight of all the possible end results.  Our job should be to ensure that
the distinction is one of business agreements, not technical agreements.

Mike

> -----Original Message-----
> From: Otmar Lendl [mailto:[email-masked]] 
> Sent: Wednesday, November 28, 2007 8:29 AM
> To: [email-masked]
> Subject: [Speermint] Review of draft-ietf-speermint-architecture-04
> 
> 
> I can't remember that we discussed that draft during the last 
> two meetings. The current agenda gives 40 mins for this 
> draft, so took another look at this document.
> 
> >Abstract
> >
> We now finally have once again a document which lists the 
> requirements on what the speermint architecture is supposed 
> to solve. That list isn't done yet, but still it would be 
> worthwhile to look at the architecture document with an eye 
> for the requirements.
> 
> As the requirements draft changed substantially recently, 
> this draft also needs to reflect this.
> 
> >2. Network Context
> >
> > 
> I see no reasons to treat Enterprises any different from 
> Service Providers. Yes, there may be legal and regulatory 
> issues specific to these cases, but from a pure protocol 
> point of view, I see no need to add this distinction. (BGP 
> doesn't care whether layer 3 peering partners are ISPs or 
> enterprises, too.)
> 
> I'm not sure whether we should include purely internal 
> functions in this document. For all we care, the terminating 
> SSP could route all calls to voicemail, to a PSTN gateway, to 
> a H.323 gate, to a Skype gateway or whatnot.
> 
> Good. As this is the crux of the matter, I recommend to 
> either completely strike the DNS/SIP/DB half-sentence or 
> *really* explain what happens.
> 
> The indirect peering option is missing here. There could be a 
> transit SSP who does noch act as PSTN gateway, but simply as SIP hop.
> 
> > 
> "mobile" in the sense of nomadic use, i.e. the current IP 
> address of the user's phone? No, that's LF territory. 
> 
> Quite to the contrary: As I see it, the primary reason for 
> the existence of speermint is that fact that this is NOT 
> TRUE. If it were true, then
> http://www.enum.at/ietf/draft-lendl-sip-peering-policy-00.html
>  on) has always been that we cannot do that. The main reasons 
> are that some SSPs will elect to only run SIP ingress points 
> within private interconnection networks and not on the public 
> Internet. Or if they do, they will be firewalled so that 
> INVITES from unwanted peers will be rejected on the IP layer. 
> Others might place restrictions on the TLS parameters of 
> incoming SIP connection: when the wrong TLS certs are 
> presented, no SIP communication is possible.
> 
> In that case the domain in the From: header does not belong 
> the transit SSP.
> 
> > 
> Can this work if customer-owned domains hosted with SSPs take 
> off the same way they did for e-mail? In other words, what 
> happens when ATT hosts the SIP service for a few thousand domains?
> 
> Perhaps there is a path via a transit SIP operator? How will 
> the initiating peer learn about this other path?
>

---

From: "Elwell, John" <[email-masked]>
Date: Thu, 29 Nov 2007 16:25:00 +0000

I agree with what Michael says here.

John 

> From: Michael Hammer (mhammer) [mailto:[email-masked]] 
> Sent: 29 November 2007 14:22
> To: Otmar Lendl; [email-masked]
> Subject: RE: [Speermint] Review of 
> draft-ietf-speermint-architecture-04
> 
> Otmar,
>

---

From: "Livingood, Jason" <[email-masked]>
Date: Thu, 29 Nov 2007 14:28:09 -0500

I agree with Michael as well.

Jason 

> From: Elwell, John [mailto:[email-masked]] 
> Sent: Thursday, November 29, 2007 11:25 AM
> To: Michael Hammer (mhammer); Otmar Lendl; [email-masked]
> > should have no effect on the protocol aspects.  However, it still 
> > needs to be identified so that folks don't lose sight of it 
> and design 
> > some roadblock into the protocol work that would prevent 
> enterprises 
> > from using it.  The technical details can have a way of 
> wandering if 
> > we lose sight of all the possible end results.  Our job 
> should be to 
> > ensure that the distinction is one of business agreements, not 
> > technical agreements.
> > 
> > Mike
> >  
> > 
> > > requirements on what the speermint architecture is supposed to 
> > > solve. That list isn't done yet, but still it would be 
> worthwhile to 
> > > look at the architecture document with an eye for the 
> requirements.
> > > 
> functions in 
> > > this document. For all we care, the terminating SSP could 
> route all 
> > > calls to voicemail, to a PSTN gateway, to a H.323 gate, 
> to a Skype 
> > > gateway or whatnot.
> > > 
> > > completely strike the DNS/SIP/DB half-sentence or
> > > Well, maybe the target domain also has some say in 
> whether it will 
> > > accept calls via SIP from the originating domain.
> > > 
> address of 
> > > the user's phone? No, that's LF territory.
> > > 
> > > I do not think we can assume that a receiving peer wants 
> to peer by 
> > > default.
> > > Quite to the contrary: As I see it, the primary reason for the 
> > > existence of speermint is that fact that this is NOT TRUE. If it 
> > > were true, then
> > >  on) has always been that we cannot do that. The main reasons are 
> > > that some SSPs will elect to only run SIP ingress points within 
> > > private interconnection networks and not on the public 
> Internet. Or 
> > > if they do, they will be firewalled so that INVITES from unwanted 
> > > peers will be rejected on the IP layer.
> > > Others might place restrictions on the TLS parameters of incoming 
> > > SIP connection: when the wrong TLS certs are presented, no SIP 
> > >       Requirement #3: the mechanisms recommended for the 
> declaration 
> > > and
> > >       Notes on solution space: for advertising 
> peer-dependent SBEs 
> > > (peer
> > > In that case the domain in the From: header does not belong the 
> > > transit SSP.
> > > 
> > > > 
> > > Perhaps there is a path via a transit SIP operator? How will the 
> > > initiating peer learn about this other path?
> > >

---

From: Otmar Lendl <[email-masked]>
Date: Thu, 29 Nov 2007 22:10:00 +0100

> I agree with Michael as well.

Fine. We all agree on the substantive issue. I have no qualms with
mentioning the enterprise and carrier examples.

Can I have some responses to the other questions I raised in my review?

/ol

---

From: "Reinaldo Penno" <[email-masked]>
Date: Fri, 30 Nov 2007 10:42:19 -0500

Hello Otmar,

I'm following the discussions and read your comments. I wanted other
people to comment before committing to make any changes to the draft.

Thanks,

Reinaldo 

> Sent: Thursday, November 29, 2007 1:10 PM
> To: [email-masked]
> Subject: Re: [Speermint] Review of 
> On 2007/11/29 20:11, "Livingood, Jason" 
> <[email-masked]> wrote:
> Fine. We all agree on the substantive issue. I have no qualms 
> with mentioning the enterprise and carrier examples.
>