Subject: [Speermint] Enterprise Peering [was Re: Intercon SP...]

From: "Bob Natale" <[email-masked]>
Date: Fri, 3 Mar 2006 09:09:03 -0500

Hi Richard:

Concerning your observation (below):
"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." 

I had the same thought when I first read Medhavi's draft, but then
concluded that, from the architectural context outlined in that draft,
the "Enterprise Peering" case was simply an instance of "Direct Peering"
between "Core SPs".

If that is an accurate and acceptable interpretation, then we could
address any functional or operational differences for the enterprise
case in the Requirements BCP.  (Currently I anticipate the need for some
degree of differentiation even if only any two or more of Access SP,
Interconnect SP (by whatever name), and Core SP remain valid via WG
consensus.)

Cheers,
BobN

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

> 
> 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

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

---

From: "Stastny Richard" <[email-masked]>
Date: Fri, 3 Mar 2006 15:57:20 +0100

Hi Bob,

> the "Enterprise Peering" case was simply an instance of "Direct
Peering"

I fear this is not so simple.

First we have to clarify if an enterprise can be a
core SP on its own and what are the minimum requirements 
to be one.

Second, we also need to consider that some enterprises
(e.g. small ones) do not want to be a core SP on its
own.

ECMA (dealing in Europe with PBX issues (they specified
e.g. QSIG) presented at the last ETSI TISPAN meeting
their view on Next Generation Corporate Networks (NGCN)

They presented five scenarios, containing everything between
direct peering and using SP for interconnect

Of course the also want both: some traffic is exchanged
via direct peering (e.g. within the enterprise and also
within federations, some traffic is going via Core-SPs

So I think we have to use both models: an NGCN as
core -SP and also an NGCN connected via access SP and
core SP

Cheers

Richard

> From: Bob Natale [mailto:[email-masked]]
> Sent: Friday, March 03, 2006 3:09 PM
> To: Stastny Richard
> Cc: [email-masked]
> Subject: Enterprise Peering [was Re: Intercon SP...]
> 
> Hi Richard:
>

---

From: "Elwell, John" <[email-masked]>
Date: Sun, 05 Mar 2006 09:58:47 +0000

Richard,

Yes, and in the peering case the main difference between an enterprise as SP
and a carrier as SP is that the enterprise SP provides service only to a
limited community of users (e.g., within an organisation), rather than to
the general public, and hence different regulatory considerations apply.
Otherwise it has very similar technical characteristics.

John

> Sent: 03 March 2006 14:57
> To: Bob Natale
> Cc: [email-masked]
> Subject: [Speermint] RE: Enterprise Peering [was Re: Intercon SP...]
> 
> Hi Bob,
> 
> > Additional remark: what is missing in your scenario is the 
> connection
> of
> > There is an additional problem lurking in these complicated 
> scenarios
> (I
> > Infrastructure ENUM, but finds out via the policy records 
> that he has
> no
> > > >    a LEC (Local Exchange Carrier) requirement and an SP 
> operating
> as
> > > an
> > > is good to know what some VoIP SPs are dealing with 
> especially when
> we
> >

---

From: "Michael Hammer \(mhammer\)" <[email-masked]>
Date: Wed, 8 Mar 2006 16:24:18 -0500

Unless, of course your enterprise is higher education. :)

Mike

> From: Elwell, John [mailto:[email-masked]] 
> Sent: Sunday, March 05, 2006 4:59 AM
> To: Stastny Richard; Bob Natale
> Cc: [email-masked]
> Subject: RE: [Speermint] RE: Enterprise Peering [was Re: 
> Intercon SP...]
> 
> Richard,
> 
> Yes, and in the peering case the main difference between an 
> enterprise as SP and a carrier as SP is that the enterprise 
> SP provides service only to a limited community of users 
> (e.g., within an organisation), rather than to the general 
> public, and hence different regulatory considerations apply.
> > First we have to clarify if an enterprise can be a core SP 
> on its own 
> > and what are the minimum requirements to be one.
> > 
> > Second, we also need to consider that some enterprises (e.g. small 
> > ones) do not want to be a core SP on its own.
> > 
> > ECMA (dealing in Europe with PBX issues (they specified e.g. QSIG) 
> > presented at the last ETSI TISPAN meeting their view on Next 
> > Generation Corporate Networks (NGCN)
> > 
> > They presented five scenarios, containing everything between direct 
> > peering and using SP for interconnect
> > 
> > Of course the also want both: some traffic is exchanged via direct 
> > peering (e.g. within the enterprise and also within 
> federations, some 
> > traffic is going via Core-SPs
> > 
> > So I think we have to use both models: an NGCN as core -SP 
> and also an 
> > NGCN connected via access SP and core SP
> > 
> > Cheers
> > 
> > Richard
> > 
> > > case in the Requirements BCP.  (Currently I anticipate 
> the need for
> > some
> > > I agree that we need to discuss this and clarify (which 
> will not be
> > easy
> > > ;-)
> > > 
> > > enterprises, that is Os and Ts having networks and 
> proxies on their
> > own.
> > > 
> > > Back to ENUM:
> > > 
> > > The assumption in Infrastructure ENUM (as currently 
> defined in ENUM
> > WG,
> > > provider hosting the number, which is translated with SRV 
> and DNS to
> > the
> > > This is ok if Core-O is querying Infrastructure ENUM and 
> no Intercon
> > is
> > > involved
> > > 
> > > Intercon already the information derived from 
> Infrastructure ENUM (=
> > the
> > > 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
> > > 
> > > 
> > > 
> > > 
> > > > >   "Origination" in this document) and terminates at 
> called party
> > "T"
> > > > >   contact center, E911 operator etc.  The first hop 
> and the last
> > hop
> > > > of
> > > > >    case, there is no intervening network.  That is, 
> for purposes
> > of
> > > > this
> > > > >    LEC may be required to allow the subscriber 
> his/her choice of
> > IXC
> > > > >    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
> > > > > Von: Livingood, Jason 
> [mailto:[email-masked]]