整合服務（Integrated Services）
/ IntServ: INT-serv /
想想你會怎麼為一大群人保證一頓好餐：事先打電話、為你這一桌人數訂位，餐廳就會留下座位、為你做好準備。整合服務（IntServ）就是把這個訂位的想法用在網路上。在送出一條即時流之前，應用程式請求網路保留資源——沿著從發送端到接收端的整條路徑，保留特定數量的頻寬與一個延遲上限——網路要嘛批准這項保留（接納這條流），要嘛拒絕它（於是它無法開始、也就不會毀了別人）。它承諾的是逐流的品質，而不只是逐類別的偏袒。
它透過一個叫 RSVP（資源保留協定）的信令協定運作。發送端描述它的流量（常以權杖桶設定檔表示：平均速率與爆發量），接收端則沿著路徑回送一個 RSVP 保留請求。路上每一台路由器都執行接納控制：它檢查在它所有既有的保留之上，是否還有足夠的閒置容量來滿足這條流的請求。若路徑上每一台路由器都說好，保留就逐跳安裝下去，這條流便獲得保證；若任何一台路由器裝不下它，保留就被拒絕。每一台路由器接著必須保持逐流的狀態並據此排程（例如以加權公平佇列），才能真正兌現它所承諾的。
為什麼重要：IntServ 能提供最強的保證——對頻寬與有界延遲的真正逐流承諾——這正是一通敏感的視訊通話會想要的。但它帶著沉重而誠實的代價：路徑上每一台路由器都必須記住並監管每一條個別流的狀態。在一台承載數百萬條同時流的骨幹路由器上，那種逐流的狀態與處理根本無法擴展。這正是為什麼網際網路大致從 IntServ 轉向較粗略、核心無狀態的區分服務模型，也是為什麼 IntServ 今天大多見於較小、受控的網路，而非橫跨全球網際網路。
一個視訊應用想要 4 Mbps 與一個緊的延遲上限。透過 RSVP，路徑上每一台路由器檢查它的閒置容量；路由器 1 到 4 都裝得下，於是它們安裝這項保留，通話獲得保證。若路由器 3 已滿，這項保留就會被拒絕，應用會被告知它得不到保證。
IntServ 透過 RSVP 逐跳保留逐流資源——一個保證，但在每台路由器上都有狀態。
IntServ 致命的擴展問題在於逐流狀態：一台核心路由器得追蹤並排程數百萬條個別的保留。這就是為什麼網際網路偏向 DiffServ，後者以流量類別而非個別流來運作，讓核心保持無狀態。