1. FRD Examples
November 28, 2017
L. Ong

2. Functional Requirements Document Review
Currently in draft, posted on github
Terminology, main text and appendices
Terminology – check for alignment with MEF agreements
Main text – check for terminology consistency with UML, add section on OAM
Appendices – review, potentially add more examples
Appendix Extensions Discussion from F2F
Notification example – notification of state changes
Multilayer/Multidomain example with option B (separation of layer connectivity services)
TBD
OAM example – creation, activation of monitoring

3. Notification Example Static object state change
Link deterioration/failure
Link update
Dynamic object state change
Connectivity Service to Installed
Connectivity Service to Deleted
Steps
Identification of object for state change notification
Subscription to state change notification
Unsubscription to state change notification or object deleted

4. Use Cases (distinguish Demo and FRD)
Link failure (port?) – topology update – path computation input
Automatic? Or subscribe -
Currently only poll, do not get autonomous notification of change
connService provisioning state (demo vs. FRD)
Automatic subscription – could be by creator or other, e.g,. Alarm center (for all services)
Optimization – automatically subscribe on creating service? Or automatically subscribe to all service creation – for Demo
Note CT testing – used websockets but did not have explicit subscription needed
Bandwidth change?
connService failure
MEPs– OAM service – MIPs – fault analysis – retrieve log?
More complex – pkt counter not changing, queue overflow?
Lower priority (need understanding) - “telemetry” – instantaneous or periodic update of current state (or “no change”)
Fault isolation?
YANG
Configuration state change
Operational state change – against services? Current TAPI – initial focus

5. Notification Model Processing Multi-Domain Controller
Node Edge Point (Network Internal) 1
Service Interface Point
Node Edge Point (Network Edge)
1.G
TAPI Context-G
10.G
2.R
TAPI Context-R
9.R
Processing
3.G
11.G
4.R
12.R
Multi-Domain Controller
Notification Client
Notification Client
1.D1
TAPI Context-1
5.D1
5.D2
TAPI Context-2
7.D2
7.D3
TAPI Context-3
11.D3
2.D1
6.D1
6.D2
8.D2
8.D3
12.D3
3.D1
4.D1
9.D3
10.D3
Domain-1 Controller
Domain-2 Controller
Domain-3 Controller
Notification Server
Notification Server
Notification Server
MD Controller Internal View (not exposed) D1 D3
1.G
1.D1
D1-e
D3-1e
11.D3
11.G
2.R
2.D1
12.D3
12.R
3.G
3.D1
D3-2e
10.D3
10.G
4.R
4.D1
9.D3
9.R
TL1.D3
TL.D1 D2
TL2.D3
D1-o
D3-2o
D2-1o
D2-3o
5.D1
5.D2
7.D2
7.D3
D3-3o
D3-1o
6.D1
6.D2
8.D2
8.D3
D2-2o
D3-4o

6. Notification Example Processing Multi-Domain Controller
GET notification types and availability
POST subscribe to notification of all connService state changes
Notifications via websocket to MD Controller
POST subscribe to notification of Link state changes with new destination
Notifications via websocket to alternate destination processing
Notification Example
Node Edge Point (Network Internal) 1
Service Interface Point
Node Edge Point (Network Edge)
1.G
TAPI Context-G
10.G
2.R
TAPI Context-R
9.R
Processing
3.G
11.G
4.R
12.R
Multi-Domain Controller
Notification Client
Notification Client 5 1
1.D1
TAPI Context-1
5.D1 4
5.D2
TAPI Context-2
7.D2 1 2
7.D3
TAPI Context-3
11.D3 3
2.D1
6.D1
6.D2
8.D2
8.D3
12.D3
3.D1
4.D1
9.D3
10.D3
Domain-1 Controller
Domain-2 Controller
Domain-3 Controller
Notification Server
Notification Server
Notification Server
MD Controller Internal View (not exposed) D1 D3
1.G
1.D1
D1-e
D3-1e
11.D3
11.G
2.R
2.D1
12.D3
12.R
3.G
3.D1
D3-2e
10.D3
10.G
4.R
4.D1
9.D3
9.R
TL1.D3
TL.D1 D2
TL2.D3
D1-o
D3-2o
D2-1o
D2-3o
5.D1
5.D2
7.D2
7.D3
D3-3o
D3-1o
6.D1
6.D2
8.D2
8.D3
D2-2o
D3-4o

7. Notes Filter – describe how to use this to control subscription
Agreed to add text to FRD draft for review

8. Service Example 10G EPL (Option A)
Node Edge Point (Internal)
Service End Point
Node Edge Point (Edge)
Link
Transitional Link
Connection EndPoint
Service Interface Point 1 13
1.G
TAPI Context-G
10.G
2.R
TAPI Context-R
9.R
3.G
11.G
4.R
12.R
Multi-Domain Controller 2 12 3 5 6 8 9 11
1.D1
TAPI Context-1
5.D1
5.D2
TAPI Context-2
7.D2
7.D3
TAPI Context-3
11.D3
2.D1
6.D1
6.D2
8.D2
8.D3
12.D3
3.D1
4.D1
9.D3
10.D3 4
Domain-1 Controller 7
Domain-2 Controller 10
Domain-3 Controller
Domain-1
Domain-2
Domain-3
UNI
NNI
UNI
NNI
D1-4
D3-4
G-1
G-2 1
D2-1
D2-3 11
D1-1
D1-3 5 7
D3-3
D3-1
R-1 2
D1-2 6 8
R-2
D2-2
D3-2 12
UNI 3 4 9 10
UNI
G-3
R-3
R-4
G-4

9. Multilayer/multidomain example (Option B) - Multilayer View
MD Controller Internal View (not exposed to end user) D1 D3
1.G
1.D1
D1-e
D3-1e
11.D3
11.G
2.R
2.D1
12.D3
12.R
13.D3
3.G
3.D1
D3-2e
10.D3
10.G
4.R
4.D1
9.D3
9.R
7.D1 D2
8.D1
D1-o
D3-2o
D2-1o
D2-3o
5.D1
5.D2
7.D2
7.D3
D3-3o
14.D3
D3-1o
8.D2
8.D3
6.D1
6.D2
D2-2o
D3-4o

10. Create server layer connectivity service
MD Controller Internal View (not exposed to end user)
D1-e D3
1.G
1.D1
D1-e
D3-1e
11.D3
11.G
2.R
2.D1
12.D3
12.R
13.D3
3.G
3.D1
D3-2e
10.D3
10.G
4.R
4.D1
7.D1
9.D3
9.R D2
D1-o
D3-2o
8.D1
D2-1o
D2-3o
5.D1
5.D2
7.D2
7.D3
D3-3o
14.D3
D3-1o
8.D2
8.D3
6.D1
6.D2
D2-2o
D3-4o
connServ Request (8.D1; 5.D1; OTN) + connServ Request (5.D2; 7.D2; OTN) + connServ Request (7.D3; 14.D3; OTN)
Should there be multiple SIPs or single SIP per transitional link?
Original FRD suggested separate SIPs, contribution .041 suggests single SIP?
Single SIP per transitional link might be an alternative – specific to mapping

11. Create server layer connectivity service
MD Controller Internal View (not exposed to end user)
D1-e D3
1.G
1.D1
D1-e
D3-1e
11.D3
11.G
2.R
2.D1
12.D3
12.R
13.D3
3.G
3.D1
D3-2e
10.D3
10.G
4.R
4.D1
7.D1
9.D3
9.R D2
8.D1
D1-o
D3-2o
D2-1o
D2-3o
5.D1
5.D2
7.D2
7.D3
D3-3o
14.D3
D3-1o
8.D2
8.D3
6.D1
6.D2
D2-2o
D3-4o
connServ Request (8.D1; 5.D1; OTN) + connServ Request (5.D2; 7.D2; OTN) + connServ Request (7.D3; 14.D3; OTN)
Should there be multiple SIPs or single SIP per transitional link?
Original FRD suggested separate SIPs, contribution .041 suggests single SIP?
Multiple SIPs seems preferable to maintain separation of layers

12. Create client layer connectivity service
MD Controller Internal View (not exposed to end user) D1 D3
1.G
1.D1
D1-e
D3-1e
11.D3
11.G
2.R
2.D1
12.D3
12.R
13.D3
3.G
3.D1
D3-2e
10.D3
10.G
4.R
4.D1
9.D3
9.R
7.D1 D2
8.D1
D1-o
D3-2o
D2-1o
D2-3o
5.D1
5.D2
7.D2
7.D3
D3-3o
14.D3
D3-1o
8.D2
8.D3
6.D1
6.D2
D2-2o
D3-4o
connServ Request (1.D1; 7.D1; ETH) + connServ Request (13.D3; 11.D3; ETH)
Capacity of transitional link could be greater than single server layer link
Capacity of TL pool is reduced by allocation to a client service
Need to be able to point to specific ODU

13. Create server layer connectivity service
MD Controller Internal View (not exposed to end user)
D1-e D3
1.G
1.D1
D1-e
D3-1e
11.D3
11.G
2.R
2.D1
12.D3
12.R
13.D3
3.G
3.D1
D3-2e
10.D3
10.G
4.R
4.D1
7.D1
9.D3
9.R D2
D1-o
D3-2o
8.D1
D2-1o
D2-3o
5.D1
5.D2
7.D2
7.D3
D3-3o
14.D3
D3-1o
8.D2
8.D3
6.D1
6.D2
D2-2o
D3-4o
connServ Request (8.D1; 5.D1; OTN) + connServ Request (5.D2; 7.D2; OTN) + connServ Request (7.D3; 14.D3; OTN)
Create new NEP, pull this out of the TL NEP pool
Two NEPs, one in each layer could be created
Server layer NEP could support multiple clients

14. Create client layer connectivity service
MD Controller Internal View (not exposed to end user) D1 D3
1.G
1.D1
D1-e
D3-1e
11.D3
11.G
2.R
2.D1
12.D3
12.R
13.D3
3.G
3.D1
D3-2e
10.D3
10.G
4.R
4.D1
9.D3
9.R
7.D1 D2
8.D1
D1-o
D3-2o
D2-1o
D2-3o
5.D1
5.D2
7.D2
7.D3
D3-3o
14.D3
D3-1o
8.D2
8.D3
6.D1
6.D2
D2-2o
D3-4o
connServ Request (1.D1; 7.D1; ETH) + connServ Request (13.D3; 11.D3; ETH)
Generate new NEP from the original pool – specific resource used by the connection supporting the service

15. Alternative with one SIP per TL
MD Controller Internal View (not exposed) D1 D3
1.G
1.D1
D1-e
D3-1e
11.D3
11.G
2.R
2.D1
12.D3
12.R
3.G
3.D1
D3-2e
10.D3
10.G
4.R
4.D1
9.D3
9.R
13.D3
7.D1
14.D3 D2
D3-2o
D1-o
D2-1o
D2-3o
5.D1
5.D2
7.D2
7.D3
D3-3o
D3-1o
8.D2
8.D3
6.D1
6.D2
D2-2o
D3-4o
connServ Request (7.D1; 5.D1; OTN) + connServ Request (5.D2; 7.D2; OTN) + connServ Request (7.D3; 13.D3; OTN)
Consensus against this, does not separate layers sufficiently

16. Alternative with one SIP per TL
MD Controller Internal View (not exposed) D1 D3
1.G
1.D1
D1-e
D3-1e
11.D3
11.G
2.R
2.D1
12.D3
12.R
3.G
3.D1
D3-2e
10.D3
10.G
4.R
4.D1
9.D3
9.R
13.D3
7.D1
14.D3 D2
D3-2o
D1-o
D2-1o
D2-3o
5.D1
5.D2
7.D2
7.D3
D3-3o
D3-1o
8.D2
8.D3
6.D1
6.D2
D2-2o
D3-4o
connServ Request (1.D1; 7.D1; ETH) + connServ Request (13.D3; 11.D3; ETH)
Q: how do you know which ODU is being used in the OTN domain? Does not separate Ethernet and OTN layers cleanly
Transitional link is only for path computation, not actually part of the resources used
ODU service should stand by itself – should be able to create another service across server layer

17. TL with multiple client layers – different topologies (onf2017.041.04)
Access Links 1 and 2 are STM-N while access links 3 and 4 are ETH. A common set of server-layer OTN potential TTPs exist in NEP-07
If a server layer connection is created to support one client layer link, the server layer available capacity is reduces for both client layers
TAPI Context-1
Physical Box View (internal)
Node Edge Point (Internal)
Service End Point
Node Edge Point (Edge)
Link
Transitional Link
Mapping
Topology
Node
Connection EndPoint
Connection
Connectivity Service
D1s
Domain-1
1.D1
D1-s
UNI 01
NNI
3.D1 03
D1-4
D1-e
G-1
2.D1 02 09 1
D1-1
D1-3 5
4.D1 04
D1e 08
R-1 2 6
TL.D1
D1-2 07
D1-o
Added during the T-API call on April 18
UNI 3 4 05
5.D1
G-3
R-3 06
6.D1
D1o
Is this one TL or two TLs? That would lead to multiple SIPs instead, one per TL termination

18. TL with multiple client layers – different topologies (onf2017.041.04)
Access Links 1 and 2 are STM-N while access links 3 and 4 are ETH. A common set of server-layer OTN potential TTPs exist in NEP-07
If a server layer connection is created to support one client layer link, the server layer available capacity is reduces for both client layers
TAPI Context-1
Physical Box View (internal)
Node Edge Point (Internal)
Service End Point
Node Edge Point (Edge)
Link
Transitional Link
Mapping
Topology
Node
Connection EndPoint
Connection
Connectivity Service
D1s
Domain-1
1.D1
D1-s
UNI 01
NNI
3.D1 03
D1-4
D1-e
G-1
2.D1 02 09 1
D1-1
D1-3 5
4.D1 04
D1e
TL1.D1 08
R-1 2 6
D1-2
TL2.D1 07
TL3.D1
D1-o
Added during the T-API call on April 18
UNI 3 4 05
5.D1
G-3
R-3 06
6.D1
D1o
With three SIPs instead of one