Subject: [Speermint] Intercon SP (was I-D draft-bhatia-sip-peering-00.txt)

From: "Stastny Richard" <[email-masked]>
Date: Fri, 3 Mar 2006 10:41:14 +0100

> 
> I think maybe the draft needs to clarify that Interconnect SP is not
the
> same as Transit.
> We can try to do this if lot of people feel the same and it really
> affects the routing
> architecture selection (IMHO - it should not have any effect) in the
> end.

I agree that we need to discuss this and clarify
(which will not be easy ;-)

I know that currently Interconnect SP (on L5) are existing
and providing a kind of clearing house function regarding
call routing (some also provide ENUM) and also providing
policy services.

Some also provide L3 transit, some not.

To complicate issues further, some work as proxies
(as in your Figure 1), some as redirect servers.

GSMA is planning to introduce such Intercon proxies
within their GRX/IPX network (called hub/IPX proxies)
(Note GRX/IPX is also always a mediastream transit network)

Additional remark: what is missing in your scenario
is the connection of enterprises, that is Os and Ts
having networks and proxies on their own.

Back to ENUM:

There is an additional problem lurking in these
complicated scenarios (I am somewhat referring
back here to my previous e-mail on phone numbers)

The assumption in User ENUM is that you get
back the AoR out of ENUM = the Core-T
the user defined to provide VoIP services 
for him (not necessarily the provider 
hosting the number)

The assumption in Infrastructure ENUM (as
currently defined in ENUM WG, not private ENUMs)
that you get back either also the AoR of the SP
provider hosting the number, which is translated
with SRV and DNS to the ingress border element
of the Core-T, or directly the ingress element

This is ok if Core-O is querying Infrastructure
ENUM and no Intercon is involved

So what is the mechanism to involve an Intercon SP?

One scenario I could imagine is the following
A Core-O is querying Infrastructure ENUM, but
finds out via the policy records that he has
no direct peering with the Core-T.

He may now forward the call to an Intercon SP which
is providing connectivity to the Core-T. He may
have some choices.

How is the Intercon SP announcing which Core-Ts
he is able to terminate?

This could of course be done by the Core-T in
the policy records giving the Intercon SP in
his federation list.

The question I have now is does the Core-O 
provider signal to the Intercon already the
information derived from Infrastructure ENUM
(= the Core-T URI) or does he give again
the E.164 number and the Intercon SP is
querying Infrastructure ENUM again.

This may not sound complicated if we assume
only one global Infrastructure ENUM, but if we take
into account that we may also interwork with
private ENUMs?

Example:

GSMA decides to be reachable also from the 
Internet, but in public Infrastructure ENUM
only the ingress border elements from IPX are
entered. This requires a second ENUM query
within IPX, which in turn requires the original
E.164 number to be kept.

Since I am currently also dealing with the
header field nightmare in SIP and IMS, we
may need to make the e.g. P-Called-Party-ID
Header from RFC 3455 mandatory.

Cheers

Richard

> -----Original Message-----
> From: Medhavi Bhatia [mailto:[email-masked]]
> Sent: Thursday, March 02, 2006 11:03 PM
> To: Stastny Richard; Livingood, Jason; [email-masked]
> Subject: RE: [Speermint] FW: I-D draft-bhatia-sip-peering-00.txt
> 
> Hi Richard,
> 
> Sorry about the headache...
> Hopefully my answers below will help :)
> Thanks for the quick read anyway.
> 
> Cheers,
> Medhavi.
> 
> >
> > >The purpose of this document is to help the IETF community
understand
> >
> > >   the route architectures being used today in SIP based peering
> >
> > >   environments and to outline a set of requirements based on the
> same
> >
> > >   for discussion within the community
> >
> >
> >
> > Is this IMS in stealth mode?
> 
> The intent of the draft is to describe what is deployed and the
> requirements driving that. We can choose to ignore or accept some of
> them based on WG discussion.
> 
> (IMHO - I don't think IMS is deployed anywhere :)
> 
> >
> > The abstract should clearly state:
> >
> >
> >
> > The purpose of this draft is to help the IETF community understand
IMS
> ..
> >
> >
> >
> > In particular I have problems with the following para:
> >
> >
> >
> > "The call is originated at calling party "O", (called the
> >   "Origination" in this document) and terminates at called party "T"
> >   (called the "Termination" in this document).  T may be a
subscriber,
> >   contact center, E911 operator etc.  The first hop and the last hop
> of
> >   the call in Figure 1 pass through SPs providing L5 (in our case
SIP)
> >   access to the origination and termination and are called Access-O
> and
> >   Access-T respectively.  In most cases these SPs will also provide
> the
> >   physical access to the origination and termination devices.  The
> >   Access SP function is not optional.  While a separate Access SP
may
> >   not exist, the function may be absorbed by the corresponding Core
> SP."
> >
> > A Core SP ALWAYS needs an Access SP if he is not providing the
access
> > by itself? In L5?
> >
> 
> It says three things: (a) Access SP is mandatory (b) Access SP "may"
> provide
> physical access (c) Access SP can be absorbed within the Core SP.
Maybe
> the
> language can be improved, but I think we capture the case you are
> talking
> about - an ASP (Vonage) like scenario!
> 
> > And then we also have Interconnect SP = Transit
> >
> > What happened to the SIP Trapeziod?
> >
> 
> SIP Trapezoid is captured, since the Interconnect SP is optional
(first
> para on pg 4).
> However, I think there could be a special section devoted to that.
Note
> that in no way
> the draft is supposed to be prescriptive or designed to ignore the
> trapezoid. Sorry if it sounds
> confusing -  we can fix that problem...
> 
> Also, Note that Inteconnect SPs today don't map to "Transit" as
defined
> in requirements
> draft.
> 
> > and may I remember on the req draft
> >
> > "3.6.2.  Layer 5 Peering
> >
> >    Layer 5 peering refers to interconnection of two service
providers
> >    for the purposes of SIP signaling.  Note that in the layer 5
> peering
> >    case, there is no intervening network.  That is, for purposes of
> this
> >    discussion, there is no such thing as a "Layer 5 Transit
Network"."
> >
> > The next problem I have with section
> >
> 
> I think maybe the draft needs to clarify that Interconnect SP is not
the
> same as Transit.
> We can try to do this if lot of people feel the same and it really
> affects the routing
> architecture selection (IMHO - it should not have any effect) in the
> end.
> 
> >
> >
> > "5.2.  Addressing
> >
> >    The type of A-O-R for the termination may also affect what kind
of
> >    address location service is used.  Address location is done
> typically
> >    based on the following four characteristics of the termination's
> AOR.
> >    In each case, we list the most common address location method
used.
> >
> >
> >    1.  Full E.164: ENUM or SP's local policy may be used.
> >    2.  E.164 prefixes: SPs local policy is generally used.
> >    3.  Full A-O-R: This is rarely used for routing in a peering
> >        environment.
> >    4.  Domain of A-O-R: DNS SRV or SPs local policy may be used."
> >
> >
> >
> > Within SPEERMINT only Call Routing Data (CRD) are used
> >
> > E.164 numbers are not CRD, they are also not A-o-R,
> >
> > E.164 numbers are names
> >
> > so E.164 number is out of scope in SPEERMENT
> >
> 
> I am not sure what I need to fix, but we can address it after WG
> discussion.
> 
> >
> > And IMHO completely off is the idea to introduce
> > carrier selection within VoIP
> >
> > " For example Equal Access is
> >    a LEC (Local Exchange Carrier) requirement and an SP operating as
> an
> >    LEC may be required to allow the subscriber his/her choice of IXC
> >    (IntereXchange Carrier) for certain set of calls.  In essence,
> these
> >    requirements may affect route policy for peering where the
> downstream
> >    peer is chosen based on origination's policy.  In this case, the
> >    Core-O and Core-T may be one and the same SP who peer through an
> >    Interconnect SP of the origination's choice."
> >
> 
> Equal Access gives a headache to anyone dealing with VoIP :). I think
it
> is good to know what some VoIP SPs are dealing with especially when we
> are starting discussions in the WG. As the draft says  in the last
para
> - it is
> possible that this may affect only a minor set of deployments in the
> end. Time
> will tell. Also, Equal Access is simply an example (I can't promise if
> there
> are not a host of other scenarios out there).
> 
> Thanks,
> Medhavi.
> 
> 
> 
> > I have an headache
> >
> > Richard
> >
> > ________________________________
> >
> > Von: Livingood, Jason [mailto:[email-masked]]
> > Gesendet: Do 02.03.2006 19:33
> > An: [email-masked]
> > Betreff: [Speermint] FW: I-D draft-bhatia-sip-peering-00.txt
> >
> >
> > FYI for the WG on this draft.  This is on the tentative agenda at
the
> Dallas meeting (should
> > be finalized shortly).
> >
> > Jason
> >
> > ________________________________
> >
> > From: Medhavi Bhatia [mailto:[email-masked]]
> > Sent: Sunday, February 26, 2006 12:44 AM
> > To: [email-masked]
> > Cc: [email-masked]; Livingood, Jason
> > Subject: I-D draft-bhatia-sip-peering-00.txt
> >
> >
> >
> > Abstract
> >
> >
> >
> >    The purpose of this document is to help the IETF community
> understand
> >
> >    the route architectures being used today in SIP based peering
> >
> >    environments and to outline a set of requirements based on the
same
> >
> >    for discussion within the community.
> >
> >
> >
> >
> >
> >
> > _______________________________________________
> > Speermint mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/speermint
> >
> > --
> > No virus found in this incoming message.
> > Checked by AVG Free Edition.
> > Version: 7.1.375 / Virus Database: 268.1.1/272 - Release Date:
> 3/1/2006
> >

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

---

From: "Medhavi Bhatia" <[email-masked]>
Date: Fri, 3 Mar 2006 11:44:51 -0500

Richard,

You have raised some interesting problems below. I am sure there will be
a lot of discussion around this. Anyway, my comments are below:

-Medhavi.

> From: Stastny Richard [mailto:[email-masked]]
> Sent: Friday, March 03, 2006 4:41 AM
> To: Medhavi Bhatia; Livingood, Jason; [email-masked]
> Subject: Intercon SP (was I-D draft-bhatia-sip-peering-00.txt)
> 
> >

I think this case is handled as long as the network which O has acts as
its Core SP. In other words the SP in the middle is purely an
Interconnect (I prefer inventing a new term such as IXP for these folks
doing this). If the scenario is that O has a network but it is separate
from Core-O (which is an SP), then that network may be classified as
either Access SP or one of the IXPs in the middle. 

In terms of requirements, this does raise the question how does an
Enterprise advertise or announce the numbers. There are other
requirements of course for direct or hosted services used by the
enterprise (like some sort of controlled access control policies or
B2B).

> How is the Intercon SP announcing which Core-Ts

I think this is a very important question for the WG. I was implicitly
assuming some sort of private ENUM (hop by hop basis), but we need to
answer all the questions you have below. I think the IPX (GRX folks)
have this problem today. The Core-O does an ENUM dip and gets the IPX
border element's domain address. Following this, the IPX border element
is doing another ENUM dip to get to Core-T. The second option is that
Core-O does the dip and gets the domain for Core-T. Now using business
policies it decides that the best way to get to it is to get through the
IXP (IPX :) it has an agreement with. The IXP then does the dip again to
route the call to Core-T. The problem here is that there is local policy
Core-O used to get to the IXP. I think some folks may say that we need
not solve this problem in the WG given that the IXP may want to control
that based on business arrangements. However I think there will be
"free" or low cost or "better" IXPs who would want to enlist themselves
in some sort of federation (I think you refer to this model as well). At
best this should be another ENUM dip kept separate from the previous one
(which is used by everyone). This ENUM dip would be done for the Core-T
domain and the result will be the IXP list and the dip could be done to
the IXP federation ENUM server.

3/1/2006

---

From: "Stastny Richard" <[email-masked]>
Date: Fri, 3 Mar 2006 19:05:59 +0100

Medhavi,
 
>I am sure there will be a lot of discussion around this
 
You can bet on this ;-)
 
>either Access SP or one of the IXPs in the middle.

IMHO it is required to define the task of each SP in the chain exactly

What are the tasks and purposes of an Access SP?

Simple proxying Register and Invite messages between
the o and the Core-O, Or are there additional functions?

E.G providing emergency dial strings as currently discussed in ECRIT
act as an Emergency Service Routing Proxy. What else?

>enterprise (like some sort of controlled access control policies or

Regarding E.164 numbers there is an intersting issue with
Infratsructure ENUM. An enterprise may have e.g. a geo-number
which is hosted by a Core-T. The enterprise may have in addition a 
national corporate number or an 800 number assigned directly 
to the enterprise by the NRA. The enterprise may decide now
to host this number either with another SP or even point this
number directly to his proxy, acting in this case as Core-T

Regarding you answer below on different
ENUM dips (private, IXP and global Infrastructure)
one should alweay keep the prime purpose of
Infrastructure ENUM in mind: saving admistrative
cost (OPEX).

The basic idea of ENUM is that the Core-T hosting
the number is administrating his own numbers only
and all other Core-O are querying these numbers

If a Core-O is running and querying a private
ENUM database, one has first to ask the question
where are the data coming from? definitely not from
the Core-T. Who is maintaing the data, if eg a number
is ported in another country an now moving from
one IXP to the other?

cheers

Richard

Von: Medhavi Bhatia [mailto:[email-masked]]
Gesendet: Fr 03.03.2006 17:44
An: Stastny Richard; Livingood, Jason; [email-masked]
Betreff: RE: Intercon SP (was I-D draft-bhatia-sip-peering-00.txt)

Richard,

-Medhavi.

3/1/2006