Subject: [Speermint] Basic Peering Requirements

From: Daryl Malas <[email-masked]>
Date: Thu, 05 Oct 2006 16:38:02 -0600

I was asked at the interim meeting to put together a list of base-level
peering requirements by Jean-francois.  I put together a list and tried
to send it to him, but I'm not sure it ever made it.  In either case, I
wanted to post it to the list, so the WG will have ample time to pummel
it before San Diego. ;-)

----------------------------------------------------------------------

Jean-Francois,

Per our conversation in Philadelphia, I have compiled a list of basic
peering requirements from one operators perspective.  I can post these
to the list if you would like.  Here is a list of peering requirements
(this is certainly not exhaustive, but is a platform):

Transport (Layer 1  3):

Peering must utilize IP as the primary mechanism for peering. 

A federation must agree upon a common mechanism for IP transport either
private (e.g. IPVPN, IPSEC, etc.) or public. 

(Net of this...most operators will peer with these methods today.)

Billing:

If peering services involve billing, the peers or federation must agree
on a common monetary policy. 

The peers or federation must agree on a common currency. 

(Net of this...some customers may abuse peering, and operators may want
to bill for certain traffic pattern types (e.g. Layer 3 IP Peering
Leaches).)

Policy:

Policies may be implemented locally to the peer or via a centralized
mechanism within the federation. 

Local policies should be disclosed when creating direct peering
relationships with the applicable direct peer. 

Local policies may supersede centralized federation policies. 

(Net of this...some peering relationships will be 1:1, so policies will
likely be local only.  Some peering relationships will be 1:N, so
policies will likely be implemented within DNS or some centralized
mechanism.)

Membership:

A peer may be a member of multiple federations 

A peer must maintain compliancy for policies as defined by each
federation the peer is a member of. 

If a peer is providing connectivity to multiple federations, it should
disclose AoRs providing indirect peering relationships to servicing
peers or federations. 

Peers providing indirect peering must enforce federation policies on
behalf of the destination federation. 

A peer providing indirect peering may enforce undisclosed policies for
processing session requests between federations. 

(Net of this...some peers will only desire to be part of a single
federation, where wholesale carriers will likely be members of multiple
federations.)

Media:

Peers must agree on one or more CODECs, which is either negotiated
directly or via a transcoding mechanism. 

A transcoding mechanism may exist locally or centralized within the
federation. 

(Net of this...most operators only support a couple of CODECs across the
core of their network, but will transcode at the edge.)

Routing:

A peer must utilize the centralized federation routing mechanism if it
is available. 

A peer allowing another peer within a federation to provide indirect
peering on their behalf must select only one indirect peer to host their
AoRs. 

A peer must not copy routing information from or make assumed routing
choices on behalf of the centralized routing mechanism for use locally
unless it takes place through standard caching methods. 

A common API must be utilized and available for subscriber and route
provisioning on any centralized federation location function. 

Subscriber and routing information must be dynamically updated as soon
as applicable for accurate routing within the federation. 

(Net of this...In small peering (e.g. 1:1), a REDIRECT model is simple
and not too inefficient.  In a larger peering scenario (e.g. 1:N), a
more efficient method is absolutely necessary, in comes ENUM/DNS/NAPTR.
Unfortunately, both methods will likely be necessary until wider spread
adoption of DNS methods takes place.)

Performance:

Performance metrics must be shared between peers as they apply directly
to peering signaling and media on a consistent basis within the
federation. 

(Net of this...this is just a reality otherwise; finger pointing takes
place anytime something breaks.)

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

---

From: "Stastny Richard" <[email-masked]>
Date: Fri, 6 Oct 2006 10:00:13 +0200

> disclose AoRs providing indirect peering relationships to servicing

AoRs? - You mean entry points?

> AoRs

I do not understand. An AoR is defining the destination,
How can it be hosted be an indirect peer?

Could you please explain

Richard

> -----Original Message-----
> From: Daryl Malas [mailto:[email-masked]]
> Sent: Friday, October 06, 2006 12:38 AM
> To: [email-masked]
> Subject: [Speermint] Basic Peering Requirements
>

---

From: Daryl Malas <[email-masked]>
Date: Fri, 06 Oct 2006 09:04:04 -0600

> AoRs? - You mean entry points?
Yes, my intention was to use it as described in RFC 3327.  "Each
incoming request targeted to the public address-of-record for the user
is routed to this proxy..."  The AoRs in this case are representing the
public address-of-record for the indirect peered domain(s).

I apologize if I used this term incorrectly, I felt it applied.  I can
changed the terminology if there is a problem with it. --Daryl

---

From: "Stastny Richard" <[email-masked]>
Date: Fri, 6 Oct 2006 18:47:32 +0200

So IMO the following should be replaced
 
> disclose AoRs providing indirect peering relationships to servicing
by
 
"If a peer is providing connectivity to multiple federations, it should disclose
the entry points to be used for this purpose in SRV records at the destination
domains"

 
Richard

________________________________

Von: Daryl Malas [mailto:[email-masked]]
Gesendet: Fr 06.10.2006 17:04
An: Stastny Richard
Cc: [email-masked]
Betreff: RE: [Speermint] Basic Peering Requirements

---

From: Daryl Malas <[email-masked]>
Date: Fri, 06 Oct 2006 15:57:09 -0600

> > peering on their behalf must select only one indirect peer to host their
domains.  This keeps from having multiple peers advertising within the
SRV record IP addresses to the same indirect peering domain.

If there is no requirement here, indirect peer X could be reached by
peer A, B, C...etc.  Every operator on the planet is potentially going
to try and get their SF addresses (A records) as the first choice for
indirect peer X.  It will get out of hand to quickly.  The SRV record
would return multiple A IP addresses for the SF at A, B, C.  This can
create a lot of confusion and I am suggesting we create a requirement,
which forces indirect peer X to only choose peer A's SF; or at most, 2
indirect peers, peer A and B, for example.  This does not eliminate
redundancy, as peer A can have multiple IP addresses to their SF.

Sorry...I understand your hang up...just trying to use the correct words
to communicate my thought here.

---

From: Daryl Malas <[email-masked]>
Date: Mon, 09 Oct 2006 14:48:03 -0600

Here is a simple requirement I am suggesting here:

A peer MUST specify the priority of all destination IP addresses
associated with any indirect peering resources within a Federation.
This includes A records associated with the peer's domain or IP
addresses associated with a 300 Multiple Choices response.

Does this make sense?

Thanks...--Daryl

---

From: Klaus Darilion <[email-masked]>
Date: Tue, 10 Oct 2006 17:02:45 +0200

> addresses associated with a 300 Multiple Choices response.

Multiple A records can't have priorities.

To me this does not sound like requirements, but already a design. What 
would be the requirement? I guess something like: "If a peer is not 
reachable directly, there should be means to identify a transit provider."

regards
klaus

---

From: Jim Reid <[email-masked]>
Date: Tue, 10 Oct 2006 17:47:29 +0100

> Multiple A records can't have priorities.

That's why DNS has the SRV record. :-)

---

From: "Uzelac, Adam" <[email-masked]>
Date: Tue, 10 Oct 2006 13:23:50 -0400

The requirement involves some insurance that a VSP, with multiple
transit VSPs, maintain control of sessions being routing to it through
the multiple paths.  Something to that affect.  I would like to think
that this is a bit like stating the obvious, but one never knows.
Ass-u-Me, etc, etc.

Adam

---

From: Otmar Lendl <[email-masked]>
Date: Fri, 13 Oct 2006 10:03:59 +0200

> redundancy, as peer A can have multiple IP addresses to their SF.

I have strong doubts that the existing SRV/A record scheme can be
used in a situation where there are multiple routes over competing
service providers. 

SRV/A already has serious problems as DNS answers are (unless you play
dangerous tricks) independent on who's asking. In other words, even for
simple direct peerings, the SRV/A records cannot be used to direct
different peers to different ingress points into your network.

(Yes, you could play around with DNS views or private DNS trees, but
that's just applying band-aid to a design choice.)

Overloading that already strained facility with routing information for
indirect peering is IMHO a recipe for desaster. You don't get clear
semantics (Is this indirect peering or just a different border element
of the destination?), no clear routing preferences (How to you specify
"for guys in europe, please route via X. For SPs in Asia, please route
calls to me via Y"?), and no way of extending the transit case to
more than one intermediary.

/ol
-- 
< Otmar Lendl ([email-masked]) | nic.at Systems Engineer >

---

From: Jim Reid <[email-masked]>
Date: Fri, 13 Oct 2006 09:57:38 +0100

> different peers to different ingress points into your network.

Indeed. Even if someone plays these tricks with the DNS, they won't  
work. That's because the thing making the query isn't usually the end  
client. There's usually a cacheing name server between the edge  
device and the authoritative name server.

---

From: Daryl Malas <[email-masked]>
Date: Fri, 13 Oct 2006 11:05:27 -0600

Thanks guys...you know far more about DNS than I do.  From experiences
way....back, I thought there was a way to respond to a DNS query with a
prioritized list of IP addresses associated with a domain.  So, I was
asking if a requirement should be necessary to restrict WHO can change
that prioritization (if it exists).

---

From: Otmar Lendl <[email-masked]>
Date: Mon, 16 Oct 2006 17:47:59 +0200

> that prioritization (if it exists).

SRV records are prioritized, thus yes: The RFC 3263 mechanism can
be used to communicate something like

* Try 1.2.3.4 first, 
* if that fails, try 5.6.7.8, then
* 1.3.5.7

The problem I see here is not the fact that you can't prioritize,
it is that you can't customize based on who is asking.

You can't tell carrier A to go for 1.2.3.4 first while also
telling carrier B to try 5.6.7.8 first. 

>From what I have gleaned from network operator, they do want to
tell their peering partners (independently of other peerings) quite
explicitely to which ingress point they should connect to.

That's the reason I'm not so hot on the use of NAPTR/SRV/A (as defined
in 3263 and draft-creighton-khandpur-speermint-srv-naptr-use-01).

/ol

---

From: "Stastny Richard" <[email-masked]>
Date: Mon, 16 Oct 2006 18:02:20 +0200

>in 3263 and draft-creighton-khandpur-speermint-srv-naptr-use-01).

What else? 

Richard

Von: Otmar Lendl [mailto:[email-masked]]
Gesendet: Mo 16.10.2006 17:47
An: Daryl Malas
Cc: [email-masked]
Betreff: Re: [Speermint] Basic Peering Requirements

* Try 1.2.3.4 first,

/ol

---

From: Otmar Lendl <[email-masked]>
Date: Mon, 16 Oct 2006 18:19:50 +0200

> >in 3263 and draft-creighton-khandpur-speermint-srv-naptr-use-01).

Good question.

IMHO we are sloppy with our requirements. To repeat:

| From what I have gleaned from network operators, they do want to
| tell their peering partners (independently of other peerings) quite
| explicitely to which ingress point they should connect to.

If that shows up in the final version of the speermint requirements,
then the RFC3263 NAPTR/SRV/A algorithm will not suffice.
(Unless you want to play with fire. i.e. split dns.)

Square peg, meet round hole.

Btw, our OpenSer domainpolicy code provides federations with the means
to solve this by modifying the domain name which is the input to the
RFC3263 algorithm. For the details, see
http://www.enum.at/index.php?id=dokumente

/ol

---

From: "Brian Rosen" <[email-masked]>
Date: Mon, 16 Oct 2006 12:37:33 -0400

I think federations, and peers, are fixing these problems by practical
means, which doesn't always meet the letter of the protocol "law".

Mostly, I see federations allowing per peer-pair variability in their
registry, whether it's an ENUM database, a SIP redirect, a SIP Forward or
some other mechanism.  The result is the same, for a given peer as
origination to a specific peer as termination, a specific (list of) proxy
server domain name(s) is provided.  Usually, there aren't n squared values,
but in theory there could be.

Brian 

> From: Otmar Lendl [mailto:[email-masked]]
> Sent: Monday, October 16, 2006 12:20 PM
> To: Stastny Richard
> Cc: [email-masked]

---

From: Otmar Lendl <[email-masked]>
Date: Mon, 16 Oct 2006 22:39:17 +0200

> means, which doesn't always meet the letter of the protocol "law".

Sure. A lack of standardization doesn't make things impossible. There
is a lot of SIP peering going on without speermint having published a
single RFC. 

But isn't it the whole point of the speermint WG to migrate such
ad-hoc arrangements to a standardized framework? 

> but in theory there could be.

Two points here:

1) We can't just punt everything to "federation internal". That leaves
   us with nothing except federation discovery (which kind of begs the
   question why my drafts haven't been accepted as WG item as they are
   the only work I've seen which actually addresses this).

   In this case, that may well be federation internal, but what's wrong
   with providing a best practice document which gives guidance to
   federations on how to implement this?

2) The current real-life examples you list usually integrate several
   different procedures into one single lookup:

   * Number -> URI
   * Is there a peering relationship?
   * Where is the ingress SIP element of the next hop?

   That cannot be the Speermint solution as we have to cope with
   pure URI-based calls.

/ol

---

From: Daryl Malas <[email-masked]>
Date: Mon, 16 Oct 2006 17:53:25 -0600

> telling carrier B to try 5.6.7.8 first. 
No, but lets say that carrier C is hosting and managing the federation
LF, and carrier C also has SF 1.2.3.4 and carrier D has 5.6.7.8.
Carrier C gets a 2 cent kick-back (for some reason) every time a call
comes through their network.  If the indirect peer associated with
1.2.3.4 and 5.6.7.8 doesn't have the requirement to specify which is
returned in what order...Carrier C will make sure 1.2.3.4 is listed
first always in their...uh..er...cough..cough...the federations LF.  To
expand this example further...let's say carrier D actually has a larger
pipe and known (tested via PESQ or similar) higher quality than carrier
C.  Can the indirect peer tell carrier C, whom is hosting the federation
LF to change it, or do they change it themselves and no 3rd party can
change it?  All I was saying is a simple requirement stating only the
indirect peer can specify any priority might be necessary.

In a perfect world, this type of malicious behavior would never take
place, but in the real world; carrier C will likely try hard to pad
their bottom line.  Now, the indirect peer would probably be stupid to
enter an agreement with carrier C without the ability to fully manage
their "transit" choices, but it's something to keep in mind....or maybe
not?!?

I don't want to beat this horse anymore...if the group thinks this is a
non-issue...then consider this topic dropped from conversation.  I was
just throwing it out there as a possible consideration.

--Daryl

---

From: Otmar Lendl <[email-masked]>
Date: Tue, 17 Oct 2006 10:29:45 +0200

> just throwing it out there as a possible consideration.

IMHO your examples proove that the call routing over intermediaries
is a) needed and b) a rather complex issue fraught with competing
commercial, technical, and perhaps eben legal requirements.

I still think we need to work out and then nail down what the
requirements are for the routing decisions which we face in
the speermint context.

/ol

---

From: Otmar Lendl <[email-masked]>
Date: Wed, 18 Oct 2006 15:54:08 +0200

Daryl,

> (this is certainly not exhaustive, but is a platform):

Here are my comments to that list:

General: this seems to be a list providing details on what federations
have to do (or agree on). 

> private (e.g. IPVPN, IPSEC, etc.) or public. 

Fine.

> Billing:

Good.

> Policy:

Could you be a bit more specific on what you mean by "policy" in this
context? 

> policies will likely be implemented within DNS or some centralized

Could you provide some examples of such policies?

> disclose AoRs providing indirect peering relationships to servicing

Sorry, I don't understand that sentence. 

Do you mean that when a VSP adds an AoR to a federations routing 
database, then it needs to discluse whether that is a direct customer
or just a transit offer?

> federation, where wholesale carriers will likely be members of multiple

ok.

> Media:

ok.

> A peer must utilize the centralized federation routing mechanism if it

ok.

> peering on their behalf must select only one indirect peer to host their

Do you mean indirect peering *within* a federation? Let me name the
parties here:

> A peer (X) allowing another peer (Y) within a federation (F1) to provide indirect

Is the idea here that all members of F1 who want to place calls to X
need to route the calls via Y? In that case, I would not consider
X to be a member of F1. Instead, Y is providing transit services
for X.

Or you want to restrict X to be able to only select one other
VSP to host it's AoRs in total?

> as applicable for accurate routing within the federation. 

ok

> to peering signaling and media on a consistent basis within the

ok

/ol

---

From: "Stastny Richard" <[email-masked]>
Date: Wed, 18 Oct 2006 16:04:32 +0200

>database, then it needs to discluse whether that is a direct customer

Sorry, but I do not understand the whole issue:
 
An AoR is a a special type of SIP URI (a Public User Identity)
defining the destination network (administrative domain)
 
How can it be disclosed or not, especially for a transit network?
It is always public.
 
Richard

Von: Otmar Lendl [mailto:[email-masked]]
Gesendet: Mi 18.10.2006 15:54
An: Daryl Malas
Cc: [email-masked]
Betreff: Re: [Speermint] Basic Peering Requirements

Daryl,

Fine.

Good.

ok.

ok.

ok.

ok

ok

/ol

---

From: Daryl Malas <[email-masked]>
Date: Wed, 18 Oct 2006 09:16:23 -0600

> Could you be a bit more specific on what you mean by "policy" in this
IMO, a policy is a restriction of potential possibilities based on a
broadly defined SIP, media, and/or business service provided by the
destination peer or federation.

The mechanism for delivering the notification of these restrictions may
be static and/or dynamic.
> Could you provide some examples of such policies?
These were my thoughts from a previous thread discussion on this:
1.  Only 'X' CODEC(s) will be supported into federation B or Peer A's
network.
2.  Only 'n' number of peering sessions will be allowed at any given
time.
3.  Peer A will only support these 'X' SIP headers and methods
(extensions) via peering requests (In other words an Operator may not
support Redirect in and out of a federation...it's simply an example.)
--This one brings up an interesting aspect.  It might be noted a UAC
could send an OPTIONS message to a federation or peer to understand some
of these supported "aspects", but these will also likely be negotiated
up front."
4. (Adam added) 'x' number of sessions per second transaction rate.
> database, then it needs to discluse whether that is a direct customer
Yes
> X to be a member of F1. Instead, Y is providing transit services
Your assumption is correct, X is not a member of F1.  They can only
specify to allow Y (and not A, B, C, and D) to provide indirect peering
within F1.
> VSP to host it's AoRs in total?
Yes

---

From: Daryl Malas <[email-masked]>
Date: Wed, 18 Oct 2006 09:16:23 -0600

Yes
Yes

---

From: Otmar Lendl <[email-masked]>
Date: Wed, 18 Oct 2006 17:23:31 +0200

> > VSP to host it's AoRs in total?

How does multihoming (e.g. a small VSP which wants to by upstream services
from multiple transit VSPs) fit into that scheme?

/ol

---

From: Daryl Malas <[email-masked]>
Date: Wed, 18 Oct 2006 09:55:55 -0600

> from multiple transit VSPs) fit into that scheme?
Again, I talked about this in a previous thread.  A small VSP can be
multi-homed to a single transit VSP (e.g. multiple SF's).  They will
also likely be connected "indirectly" to multiple federations, which
also may be contracted to provide an indirect route back to this
federation through one of the peers.

I think this simplifies it greatly.  If we must, then I suggest a
maximum of two peers in a federation may provide indirect peering to an
external VSP.

---

From: Klaus Darilion <[email-masked]>
Date: Fri, 20 Oct 2006 12:40:46 +0200

> maximum of two peers in a federation may provide indirect peering to an

I do not think it is possible to dictate a federation how many of its 
members may provide transit peering too.

regards
klaus

-- 
Klaus Darilion
nic.at